ROM with size information

[Norman Feske]

Hi Stefan,

> We have discussed several solution strategies:
> 
> a) Provide the file through a file system session: Besides the drawback
> of unnecessary complexity this also does not give us the ability to
> specify the desired file with the session label.
> 
> b) Add content size information to the ROM session and update the fs_rom
> component to provide it. This would seem the most straightforward
> solution, but for the sacredness of the ROM session.
> 
> c) Create an updated or forked fs_rom component with the ability to
> provide single files as tar archives. This would allow us to consume the
> tar with vfs and have the size information available.
> 
> Which strategy should we prefer? Are there any other solutions that
> satisfy our requirements?

I have a bit of background info to share, and a few ideas as well.

As for background info: The lack of the size information from the ROM
session was actually a deliberate decision.

ROM modules are provided to the client as memory objects. The
granularity of those memory objects is thereby constrained by the MMU's
page size, which is 4K. There is no way to map a smaller window of
bytes. The size in pages can already be requested via the
Dataspace::size function. So for the ROM session as a mechanism for
providing memory objects, a size in bytes would not be a meaningful
addition.

More importantly, however, we found that not all boot loaders /
image-creation tools support the notion of a size of boot modules at
byte granularity. So depending on the kernel-image creation tools, one
would get a value rounded to the next page size or a byte granular
value. We found that such a leaky abstraction would be much worse than
not providing a byte-granular size value in the first place. Therefore,
we settled on the ROM session we have now. On that ground, I'd rule out
strategy (b).

Now for the ideas: Regarding the need to steer the file access via a
session label, you may find the 'chroot' component interesting. Unless
explicitly configured with a 'path' or 'path_prefix', the component
constructs the path via the client's session label. This way, the
component hands out different directories to different clients based on
the client's label. Granted, this works on a directory level rather than
a file level. But maybe your scenario could be adapted in this respect?

Wrapping the data + file-size information into a TAR archive works. So
your idea (c) looks nicely complementary to what we have today.

So I'd recommend investigating if the chroot component can be used. If
not, I'd go for variant (c).

Cheers
Norman

-- 
Dr.-Ing. Norman Feske
Genode Labs

https://www.genode-labs.com · https://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth