[coreboot] patch: add romfs to V2

[ron minnich]

On Mon, Mar 30, 2009 at 7:12 PM, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006 at gmx.net> wrote:

> The other question is whether we want to use streams unconditionally.
> I'd prefer to use such streams only in emergencies (crappy hardware).

great! how much crappy hardware is there. Is it only a part of the
past or will we see it in future.

If it is only misdesign for past boards then there is an easy solution.



>> let's get it working first.
>>
>
> I don't understand this comment. If it does not work, why would we
> commit it to the v2 tree?

OK, first, it's working in my tree.

It's a huge improvement over LAR. It's 10 times huge over what v2 does
now. I've got a patch that lets us
use the old way and LCAR. (I like the name).


> Since v3 already has LAR, any replacement has to demonstrate that is an
> improvement over LAR while not introducing additional
> limitations/problems.


This is a huge improvement over LAR.

Also, the code to come is design so that it is 100% backwards
compatible and LCAR is by default *off*. You only use it if you want
it. Hopefully, over time, 100% of us want it.


> Don't get me wrong. Substantial parts of the ROMFS design are really
> worth having (and overlap with the LAR design), but I hope the
> LAR->ROMFS move is not brownian motion motivated by the intrinsic
> coolness of a new tool. And if someone designs LAR-NG as part of GSoC,
> will we switch (again)?

It's worth having. It's why I did not back-port LAR to v2.


> Can we separate the "pointer to something" patch out and handle/commit
> it before ROMFS? I can dig up my ancient v3 patch for this.

I am not doing this for v3. This is a v2 patch.


> I can see roughly a factor of 20 slowdown. That's a bit excessive for my
> taste.

Again, is this stupid hardware design something we only see on one bad
board or might we see it again? Would be nice to know :-)


> What about 0x4c415232 instead? That's "LAR2".

harder to remember but I can entertain it.



> We need a policy for future romfs_header variants, too. Should they be
> backwards compatible? Do we want ext2-style read/write feature flags?

no. no. no. no. no. no. no. no. I'm not even that big a fan of
versioning in the current design, but there you are.
:-)

ron