No subject

driving reason to do a wholesale replacement?  I think incremental
patches would make more sense here.

Some thoughts on the format -

I do like how ROMFS simplifies the "file header".  However, I think
the use of a file type is a mistake.  I think type info can be more
appropriately conveyed in the file name.  (As a "straw man" argument,
consider ROMFS allocates four bytes for a file type; one could instead
use a four byte suffix on file names (eg, ".xip", ".exe", ".rom").)

ROMFS is essentially a collection of binary blobs.  One of these file
types (payloads) is also effectively a collection of binary blobs.  I
preferred the way LAR had one abstraction for storing blobs.
Unfortunately, LAR achieved this by adding info to the file header.
However, I think there is a "middle ground" here - for example, one
could put the ROMFS header into a file, and then every section into
its own file.

It's not clear to me how XIP code (eg, raminit in v3) would be stored
in ROMFS.

The description states that option roms would not be compressed.
Given how bloated option roms seem to be, I think compression is
desirable.


There are some improvements that I think would make LAR more useful
that I don't see in ROMFS.  One really useful feature would be to
support building a LAR from a directory of files and vice-versa.  This
would simplify the build process and make it easier for users to
add/modify payloads, option roms, etc..

Also, it would be useful to come up with some way for payloads to
reliably access the LAR even when files are compressed.  For example,
I would like to add support in SeaBIOS to extract option roms from the
LAR, but to do so would require supporting lzma, nrv2b, etc. in
SeaBIOS.  I think having every payload know about every compression
scheme is too much.  (Of course, not compressing option roms would
solve this, but I still think compressing them makes sense given how
small and slow flash tends to be.)

-Kevin