Hello Genodians
For our current use case we need to provide a single file e.g. continuous binary data with size information to a component. We cannot use to standard ROM session as it doesn't provide size information. We also need the ability to specify a file not known at development time through the session label in the deploy config as is possible with the fs_rom component.
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?
Best regards Stefan
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
-
Norman Feske -
Stefan Thöni