Patrick Georgi wrote:
It has no effect except creating a new directory. Not hooked up anywhere, not capable of doing any harm.
It harms us when someone who is not an expert sees ROMFS and mistakes it for something it is not, which has a similar name.
It also harms us when an expert sees it and shrugs at us because we are using conflicting names even though we are aware of the conflict.
Stefan Reinauer wrote:
I don't see the problem, but I'll take a suggestion.
Let's start with working out the name. :)
Yeah, bikesheds first. Then the deed!
I am sorry to learn that you feel this issue (usability, letting simple things be simple) to be so unimportant.
I guarantee you that my motivation is not to get attention to myself, but to get attention to things which I believe we as a project (and community) can benefit from improving.
I think everyone agrees that less confusion and more simplicity in coreboot is good. Clear and simple names for new technologies, in particular very central technologies, goes a long way towards less confusion and more simplicity, by making it a little easier to become familiar with everything that is involved in using coreboot.
The devil's advocate could say that code is nothing and packaging is everything. I don't think we should compromise on either, I think they compliment each other. I also think coreboot would be well served with some nicer packaging. Feedback I've received so far strongly favors v3 over v2 for one thing. I think we really nailed much build confusion by using Kconfig.
ron minnich wrote:
Shouldn't 1. and 2. be in sync somehow?
Sure. Suggest something! :-)
I don't feel particularly strongly for or against any of the names I suggested, they're all neutral and hopefully original.
Want to make use of more stuff - then maybe you need better hardware. Does that seem fair?
Yes. I think we ought to be willing, when confronted with stupid hardware, to say "Sorry, your hardware is too stupid to run coreboot".
I think it's fair. We will do our best of course. We already decided on CAR in v3, using the same logic. I think it works.
diverting huge effort for bad hardware doesn't make sense to me.
But that's what this entire project is about. Personally I believe we can allow hardware to become better. That's a big reason why I'm still around. I want state of the f*ing art power management in my laptop. I think everyone else wants it too, we just can't seem to afford developing it right now..
look, long term, if EFI happens, or if bigger BIOS happens, ROM will be memory addressable.
Yes I think so too.
I do however think it would suck to intentionally regress on m57sli, or any other board.
I should mention that the patch I will submit (once this one goes through) won't regress anything.
Yep - sorry I didn't clearly acknowledge when you said so the first time. The new functionality is optional.
We've been baking v3 for 30 months and ... we're not there except on a very few boards.
I for one have not been baking much. Yourself, Carl-Daniel, Myles and Corey are the ones I can think of having pounded the v3 dough lately, and I think improvements have been fairly steady compared to effort spent.
I consider v3 to still be in the design testing phase. The design is neither completely proven nor completely disproven. The roadmap was to get a small system running (we did Geode), then get a large system running (still pending), then review and revisit the design to fit the two extremes well, and interpolate what would be needed in between. I found this a perfect plan when we discussed it, and I still do.
v2
Until v3 has passed design testing there will be no great deal of support. The ownership of v3 lies with the team that initiated the design until the point where the design is declared sound and good for mainstream consumption.
v2 is now far ahead of v3: ACPI, SMM, S3 resume, etc. etc.
Naturally. Because less effort has been put into v3 than v2, there are more things in v2.
To put it simply, I think we have to use v3 as the "good ideas and lessons learned" testbed, and bring ideas we learned from there back into v2. And that is what I am doing.
I don't think we have to do that. I definately think design testing can continue for v3, and that eventually greatness will come of it.
It is clear that we have been unable to invest in that development. We said we would, we did to a degree, but too little too late to work for you and many others. I definately think you are doing the right thing under the circumstances.
bring the good parts of v3 into v2
Sure thing! The important thing is the end result, so I don't think it matters if v2 converges onto v3, or the other way around.
fine work has been done on v2, and it's simply not possible at this point to move all that work to v3.
I completely disagree with this however. It is totally possible but there has to be a will.
As for the name I can not stress enough how important it is
The thing is, I use a lot more than linux, so this naming thing doesn't bother me that much.
This is not about what bothers you or me. That is key.
It's what bothers people who, like us, know a lot about Linux and other kernels, who have already seen romfs somewhere, but who, unlike us, are new to coreboot. When they see romfs here, they are likely to assume that it is the same technology that they know from elsewhere, and there will be confusion. Confusion which steals time and effort from learning about any actual problems in coreboot as they apply to them. Having that confusing name in coreboot hurts the rep of our product, because it makes one fairly simple part of coreboot less than fairly simple to penetrate.
But if you want a name that is evocative of coreboot ....
I would actually prefer if it isn't. From my suggestions this morning I like compfs or compofs best but anything neutral and/or unique is what I request.
LCAR
I think that's fine too. Anything so neutral is good. Of course it's nice if the name has a clever meaning, but that would just be a bonus.
(wow, that is hard to say in many places! -- can we possibly put a few more vowels in there?)
You make an excellent point.
try to pick a good name in the next few days. But I don't want to hold this new stuff up forever while we debate on a name.
'few days' != 'forever'
LCAR is fine with me, the only thing I can say against *AR is that ISTR Jordan never liked the "archive" idea so it may be nicer to go with a name which doesn't suggest that.
ron minnich wrote:
it's not that big a deal to change it
Go for it! :)
//Peter