This patch adds CONFIG_ROMFS (let's argue the name later, please, it's not that big a deal to change it) config variable and its uses to all the Options.lb files for all mainboards. It creates that option in src/config/Options.lb
Tested under abuild.
Thanks
ron
Am 31.03.2009 18:17, schrieb ron minnich:
This patch adds CONFIG_ROMFS (let's argue the name later, please, it's not that big a deal to change it) config variable and its uses to all the Options.lb files for all mainboards. It creates that option in src/config/Options.lb
Tested under abuild.
Acked-by: Patrick Georgi patrick.georgi@coresystems.de
Regards
Thanks, r4035 ron
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
On Tue, Mar 31, 2009 at 1:31 PM, Peter Stuge peter@stuge.se wrote:
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.
Sure. But look where the people are spending their time .... it is not on v3. Where are companies putting in $$$ -- save for artec, not on v3.
30 months is too long. V2 has come very far. I learned when I started the SMP work on kontron just how far. The amount of effort to catch up is huge.
And, there are some features we lose. Abuild. The code checking stuff patrick did.
I'm not saying that no one should keep pushing v3; I am saying, however, that I have learned what I need to learn and I want to bring it back to v2.
People who wish to continue on v3 are free to do so!
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.
There has to be money. What money there is is going to v3. I can't change that.
As for the name I am still unsure. Are we really going to require that the name have no intersection with every other OS, firmware, and BIOS out there? That won't be easy ...
ron
ron minnich wrote:
Sure. But look where the people are spending their time .... it is not on v3. Where are companies putting in $$$ -- save for artec, not on v3.
I think only my company and coresystems have been strong corporate drivers in the v3 design. Today Artec can leverage that, which I think is good. I want to, and will, keep making v3 easy to deal with, just not right now. I think you're saying that you feel the same way.
30 months is too long. V2 has come very far. I learned when I started the SMP work on kontron just how far. The amount of effort to catch up is huge.
I trust that.
And, there are some features we lose. Abuild. The code checking stuff patrick did.
I'm not saying that no one should keep pushing v3; I am saying, however, that I have learned what I need to learn and I want to bring it back to v2.
Nod. I think you're making a good decision.
People who wish to continue on v3 are free to do so!
Yes! I will, slowly, but I will.
I completely disagree with this however. It is totally possible but there has to be a will.
There has to be money.
If money is the only driving factor. This is by the way also an interesting topic. We haven't tried much in the way of fundraising for the community. I think there could be ways to make that succeed.
What money there is is going to v3. I can't change that.
(v2) Well, we could try to decide on our own, by having own money.
As for the name I am still unsure. Are we really going to require that the name have no intersection with every other OS, firmware, and BIOS out there? That won't be easy ...
I think it is important to at least steer clear of other things which are not mutually exclusive with coreboot. If we're talking an fs name it's important to avoid intersection with other filesystems, ie. what is found in OS kernels. Not many firmware or BIOSes have established a filesystem name so it's easy to avoid an intersect with those.
If we're talking an *ar name, it makes similar sense to avoid e.g. tar and star. They exist somewhere else, they could theoretically be related (maybe we reused their format in our scope) but those names are poor for us, since they are in fact not related at all.
(Renaming lar to tar and creating .tar files doesn't make it compatible with any other tar. :)
//Peter
how about cbfs? from IRC. I like it.
ron
On Tue, Mar 31, 2009 at 5:26 PM, Peter Stuge peter@stuge.se wrote:
ron minnich wrote:
how about cbfs? from IRC. I like it.
Sure thing!
I like it too, and a quick acronym search shows nothing computer-related, so it's a good bet it's unique.
-Corey
-
Corey Osgood -
Patrick Georgi -
Peter Stuge -
ron minnich