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?
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
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@...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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Also, how well does the vfs server handle config updates?
On Wed, Dec 27, 2017 at 11:44 AM, Nobody III <hungryninja101@...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@...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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hello Ben,
Also, how well does the vfs server handle config updates?
the VFS does not support dynamic reconfiguration. (yet)
Can you give me more details on the status of the vfs in that regard? Specifically, how does it handle duplicates and writing?
The order of sub nodes within the top-level <vfs> node and within <dir> nodes defines how content is shadowed.
The VFS does not support copy-on-write. A file provided by a read-only file system will stay read only and cannot be changed. However, we plan to supplement copy-on-write support as a plugin later. Until then, the use case of providing an initial version of a config file that can be modified at runtime cannot be covered by the vfs. Here, we still have to use the ram_fs loaded with initial <content>.
Which filesystem/plugin provides the file? And which one is written to when a new file is created?
A new file is created on the first writeable file system mounted at the directory hosting the new file.
You may experiment with the VFS using a <ram> file system as a writeable file system and <tar> file systems for read-only content. You may also find the various noux scenarios worth looking at because they all use the VFS. In particular, they mount multiple tar archives at '/' where each tar archive contains a '/bin' directory. In the VFS, the joint content of all archives becomes visible.
Cheers Norman
-
Nobody III -
Norman Feske