improved fs_rom

[Nobody III]

Also, how well does the vfs server handle config updates?

On Wed, Dec 27, 2017 at 11:44 AM, Nobody III <hungryninja101 at ...9...>
wrote:

> The union mount sounds good, if it will work. Can you give me more details
> on the status of the vfs in that regard? Specifically, how does it handle
> duplicates and writing? Which filesystem/plugin provides the file? And
> which one is written to when a new file is created? What happens when you
> overwrite a file on a read-only filesystem when it shares a directory with
> a writeable filesystem? What about overwriting a file on a different
> filesystem than the one that it would create new files in?
>
> On Wed, Dec 27, 2017 at 10:05 AM, Norman Feske <
> norman.feske at ...1...> wrote:
>
>> Hi Ben,
>>
>> On 27.12.2017 05:26, Nobody III wrote:
>> > While working on my own "Sculpt" scenario, I saw that the fs_rom server
>> > still doesn't allow using multiple directories as sources. Being able to
>> > separate the executables, libraries, and config files would be very
>> > helpful for organizing the filesystem and providing shared libraries to
>> > programs without exposing the configuration files as well. Is there a
>> > way to do this with the components currently available, or should fs_rom
>> > (or some other component) be modified to enable ROM file separation?
>>
>> fs_rom can deal with subdirectories. It just takes the last part of the
>> label as path, which may contain "/" characters. So if your file system
>> has subdirectories like '/rom' and '/config', you may request the ROM
>> module 'pdfview' from the '/rom' directory by opening a ROM session with
>> the label "/rom/pdfview". The second piece of the puzzle is the use of
>> init's label rewriting mechanism in routing rules. Let's say we have a
>> subsystem 'PDF-viewer', which is an init instance that hosts one
>> 'pdfview' among other components as child components. The start node of
>> such a subsystem may look like this:
>>
>>   <start name="PDF-viewer">
>>     <binary name="init"/>
>>     <resource .../>
>>     <route>
>>       <service name="ROM" label="config>
>>         <child name="fs_rom" label="config/pdf_viewer.config"/>
>>       </service>
>>       <service name="ROM" label="pdfview">
>>         <child name="fs_rom" label="rom/pdfview"/>
>>       </service>
>>       ...
>>     </route>
>>   </start>
>>
>> The imporant part of the example above are the 'label' attributes in the
>> routing-target nodes. When specified, init replaces the child-provided
>> label by the one specified as attribute value.
>>
>> As another possible alternative, you may connect the 'fs_rom' not
>> directly to you file-system server but put a VFS server in between. In
>> the <vfs> of this VFS server, you can mount several other <fs> nodes at
>> the root of the <vfs> with each <fs> pointing to the real file system
>> but with a different 'root' attributes. This way, the VFS server will
>> present a "union mount" of the corresponding directories.
>>
>> Does one of the two options sounds viable for you?
>>
>> 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
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> genode-main mailing list
>> genode-main at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/genode-main
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20171227/97ab9249/attachment.html>