On Saturday, March 15, 2014 05:15:12 PM Kevin O'Connor wrote:
Did you mean to send this only to me? I'm only sending to you and not the list, but I'd prefer the discussion to be on list.
OOPS! I blame it on KMail's shitty "Reply" interface.
On Sat, Mar 15, 2014 at 01:54:47PM -0500, mrnuke wrote:
On Saturday, March 15, 2014 01:02:22 PM you wrote:
On Fri, Mar 14, 2014 at 08:58:01AM -0500, Aaron Durbin wrote:
CBFS is definitely not friendly to environments that can't map() the storage area of the CBFS itself. Beyond that in-storage format with metadata tightly coupled to the data itself leads to needing to stream large amounts of data through the working set just to locate the piece that is desired.
CBFS is a neat system for accessing flash that can be linearly mapped into memory.
If one has a flash device that can't be mapped into memory, I don't understand why one would want to use CBFS.
Last I checked, CBFS stood for "CoreBoot File System". I think that might mean it's the filesystem used by coreboot, but I'll have to double check and get back to you on that.
I don't think that's a great way to look at it. The CBFS system is clearly designed to delineate a linearly mapped area of memory. I wouldn't recommend using it for something else solely because it starts with "CB".
Trying to adapt CBFS to block devices is going to complicate the CBFS code, and it still isn't going to be a good solution for those block devices. There are a number of filesystems already developed for block devices - why not just use one of them?
And how exactly is this going to complicate CBFS code? And how would adding another filesystem parser into coreboot simplify things?
The code has a bunch of media->open(), ->close(), ->read(), etc. operations that are unnecessary for basic linear memory mapped accesses. As you've already cited, even with these "media" accessors the system still doesn't work well for not mapped flash chips.
By moving the abstraction up a layer, I posit that the CBFS code could be simpler, and the ARM code could be more capable.
The coreboot code's interaction with the "filesystem" after memory init
Aye, there's the rub: the assumption of "after memory init".
Before memory init everything is different on these non-mapped flash systems anyway. In past conversations I've been told the hardware (or builtin firmware) on these systems extracts a preset block from the flash and places it into sram, and this is how the bootblock/romstage is done on these systems. Thus the execute in place nature of bootblock/romstage in CBFS has no added value for these platforms.
(should) largely boil down to load_file(char *name, void *address, int maxsize). Why not just end the abstraction there (ie, on these arm devices, implement a completely different "load_file" function).
Did you have a look at our CBFS backending, by any chance?
Yes.
I'm sorry to be dismissive of your comments, Kevin, but it seems to me you do not fully understand the issue and its implications. I suggest you fully read this thread and "CBFS bullfart (forked from GSoC-2014 Project for Coreboot)" to get an idea of the problem and its subtleties.
I have read the thread. I concur that I do not understand.
-Kevin