On 31.03.2009 03:11, ron minnich wrote:
On Mon, Mar 30, 2009 at 5:36 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
AFAICS the proposed ROMFS code will break on the Gigabyte GA-M57SLI-S4 v2.x. Since the M57SLI is one of the best supported recent boards out there, I'd like to make supporting or not supporting one of its variants an explicit rather than an implicit choice. Short summary of the issue: ROMs larger than 512 kB or so can only be accessed in 3 byte chunks. That means you have to read every header in chunks. Direct comparisons in memory are not possible.
Actually, the code should work fine with the streams. I will rewrite the coreboot part to use them.
The other question is whether we want to use streams unconditionally. I'd prefer to use such streams only in emergencies (crappy hardware).
Besides that, I agree with Peter on naming when he wrote:
It absolutely must get a different name. Several file systems exist in Linux already with names that are similar enough to cause a lot of unneccessary confusion.
I welcome another name, but I won't accept a reject unless it comes with another name :-)
LAR2 or maybe LLAR (Lightweight LinuxBIOS ARchive) or LCAR (Lightweight Coreboot ARchive). OK, the last one may be misunderstood as a Star Trek reference.
And finally, I'd like to make sure we don't try to support multiple ROM management schemes. That would be madness. If ROMFS is the future, can we please use it in v3 as well?
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? Since v3 already has LAR, any replacement has to demonstrate that is an improvement over LAR while not introducing additional limitations/problems. (And no, bugs/misfeatures in the userspace tool do not count. If nobody has bothered to tackle them, nobody will bother to tackle similar problems with new userspace either.)
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)?
The "pointer to romfs_header at the end of the ROM" idea was rejected twice when I tried to get that in in v3. I still believe it is a good idea.
It is.
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.
struct romfs_header is missing a struct member containing the lowest accessible ROM address so you can switch to accessor functions for lower addresses. This is needed if we ever want to support the M57SLI v2.x with ROMFS.
That's an interesting idea. Or, we can just always use the stream model for ROMs. That's a bit more uniform, albeit slower.
I can see roughly a factor of 20 slowdown. That's a bit excessive for my taste.
romfs_header.version does not have to be endian-independent. If you can read the magic correctly as a number, you got the endianness right. No point in working around problems which do not exist.
There's another reason to do that. '1' is a common constants. 0x31313131 is not. I like to make important constants have complex values that can be caught from (e.g.) a JTAG memory dump.
What about 0x4c415232 instead? That's "LAR2".
Can we use some magic other than "ORBC"?
I don't see the problem, but I'll take a suggestion.
"LAR2" maybe? "ORBC" in a hex dump looks like something went really wrong with endianness.
We need a policy for future romfs_header variants, too. Should they be backwards compatible? Do we want ext2-style read/write feature flags?
Regards, Carl-Daniel