Dear Genode community,
Currently I’m working on a scenario that includes loading a file from USB
storage device (stick). I have a composition that works in principle but has
‘rough’ edges, particularly regarding detachment / reattachment of the USB
storage device. I’d like to share my approach with you and appreciate your
feedback / suggestions on what I could improve.
A rough sketch of the scenario is:
A user:
- inserts a USB storage device with candidate files in an available USB port on
the platform - x86 in this instance,
- selects one or more files on the USB storage device to load - using a custom
CLI,
- removes the USB storage device.
- (and sometime later) repeat the steps above.
A short description of the composition (top-down):
- the custom CLI component requests a file session with a rump_fs server when
handling a user command.
- the rump_fs server has a block session with a part_blk server.
- the part_blk server has a block session with the usb driver (dde_linux/x86),
using storage.
I attached a run script snippet that shows these relations.
The USB storage device is formatted with ext2fs.
My (initial) findings:
- When I insert the USB stick, the usb driver detects the mass storage device
and consequently the rump_fs server mounts the ext2fs. The CLI component can
access the filesystem and list/read/write files on the USB stick. All as
expected.
- When I remove the USB stick, the usb driver detects removal, but the rump_fs
remains unaware. The CLI component can successfully open new file system
sessions and even list the files in the root directory, even though the actual
storage device is detached...
- The rump_fs server aborts when a filesystem is not of the expected type.
- To complicate matters more, the target platform is booted from a - different
- USB stick. Currently the usb driver detects this USB stick as mass storage
device and the rump_fs aborts because the fs is not the expected ext2fs.
For the latter finding, I am aware that the usb driver supports a policy
mechanism for raw devices (in combination with the usb_report_filter
component). But to my knowledge for storage devices, such a policy mechanism
does not exist, right?
Regarding detachment / reattachment of USB storage, I understand that at
startup of this composition, the rump_fs server immediately requests a block
session at the part_blk server, which in turn requests a block session at the
usb driver. This whole blocks until a USB storage device is plugged in. When
this happens, the chain of sessions requests is setup and the file system
client can access the medium. Now if the USB storage device is detached, what
happens to the open sessions?
As a way to support detachment / reattachment of USB storage I’m thinking about
placing the rump_fs and part_blk components in a child subtree of the CLI
component that is spawned on demand and cleaned-up after use. But this seems a
bit like overkill. Am I overlooking the simple solution?
Met vriendelijke groet / kind regards,
Martijn Verschoor
Cyber Security Labs B.V. | Gooimeer 6-31 | 1411 DD Naarden | The Netherlands
+31 35 631 3253 (office) | +31 616 014 087 (mobile)
<start name="usb_drv" priority="-1">
<resource name="RAM" quantum="16M"/>
<provides>
<service name="Block" />
</provides>
<config uhci="yes" ehci="yes" xhci="yes">
<storage/>
</config>
<route>
<any-service> <parent /> <any-child /></any-service>
</route>
</start>
<start name="part_blk" priority="-1">
<resource name="RAM" quantum="10M" />
<provides><service name="Block" /></provides>
<config>
<policy label="rump_fs" partition="1"/>
</config>
<route>
<any-service><child
name="usb_drv"/><parent/><any-child/></any-service>
</route>
</start>
<start name="rump_fs" priority="-2">
<resource name="RAM" quantum="32M" />
<provides><service name="File_system"/></provides>
<config ld_verbose="yes" fs="ext2fs">
<rump quota="8M"/>
<policy label_prefix="custom_cli" root="/"
writeable="yes"/>
</config>
<route>
<any-service><child
name="part_blk"/><parent/><any-child/></any-service>
</route>
</start>
<start name="custom_cli">
<resource name="RAM" quantum="20M"/>
<route>
<service name="File_system"><child name=ârump_fsâ/>
</service>
<any-service> <parent/> <any-child/> </any-service>
</route>
</start>
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/intel
_______________________________________________
genode-main mailing list
genode-main@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main
