[SPAM] Sculpt scenario and block devices
hungryninja101 at ...9...
Sun Mar 4 23:14:44 CET 2018
Also, for right now, you should be aware that Sculpt's runtime configs
don't allocate RAM and CAPs for part_blk, so uncommenting the lines in
default_fs.config won't be enough. In my configuration, I decreased the
allocations for vfs so RAM and CAPs would be available for part_blk. That
seems to work, and is simpler than changing every runtime that uses
The official Sculpt config files should be changed to make this more
straightforward in the future.
On Mar 4, 2018 8:46 AM, "Josef Söntgen" <josef.soentgen at ...1...>
> Hello Tomasz,
> thanks for the feedback!
> * Tomasz Gajewski <tomga at ...300...> [2018-03-04 12:09:56 +0100]:
> > I can see block devices reported in /report/drivers/block_devices but I
> > have two disks so driver_manager is not marking any of my disks as
> > default.
> > Both disks are partitioned and I could give one partition exclusively to
> > Genode to continue playing with it but not whole disk.
> > […]
> > I think there are two possibilities to continue.
> > First is to change Sculpt configuration during preparing image to match
> > my configuration.
> I have a similar setup (two disks, both partitioned) and I would
> recommend to choose this option for now as you only need to change the
> fs subinit to match your setup, i.e. point 'part_blk' to the proper
> Block session and 'vfs' to the partition.
> > Second is to change implementation of some component (?driver_manager?0
> > to be flexible enough to automatically handle all my devices: disks
> > (ahci), partitions on disks (part_blk on ahci devices), usb drives
> > (usb), partitions on usb drives and expose them. Later it should be
> > possible to just select a block device which user would like to user for
> > Genode.
> > […]
> > I think that for each disk device (either ahci or usb) something should
> > start part_blk for it, check if it properly detected partitions and
> > expose them.
> I agree, having some kind of probing mechanism in place would be nice
> and is certainly something we want to address in future Sculpt
> iterations. It stands to reason where to put such a probing mechanism,
> though. I am not sure if the drivers subsystem is the proper place.
> Although it would be nice to handle Block sessions transparently for the
> other subsystems, it would increase the complexity of the mostly static
> drivers subsystem (that is, if we ignore USB providing more than its Usb
> session). The current layering of Sculpt subsystems considering
> complexity and dynamic composition is first the drivers, than run-time
> subsystem and at the very top the deploy mechanism…
> > Addtionally there should be a configuration option that could be easily
> > set in some config that would make a specific block device a default one
> > (instead of policy that marks it as default if there is only one
> > device).
> … and at the moment, to make things simple, we rely on a somewhat static
> configuration to point the deploy run-time to the depot location. Apart
> from that, however, it is perfectly fine to make all decisions in the
> run-time subsystem and, depending on the use case, even above that.
> For example, on one hand I want to change the partition table on a disk.
> That involves getting access to the whole Block device (“stop any
> running 'part_blk'”) to make the change and afterwards re-reading the
> partition table (“start 'part_blk'”). We already have a mechanism in
> place to do just that: changing the configuration of the run-time
> subsystem. On the other hand, if I just want to change the partition
> table on a freshly inserted USB disk, I can do that from within the
> deploy config — no need to change the run-time's configuration.
> > I think you already have some vision how you plan to implement that part
> > of system. Do you plan to extend driver manager implementation?
> It really boils down to which services are necessary at which layer for
> the rest of the system to work and what we need to do to use them
> conveniently. If this requires extending the driver manager, we will
> probably do that (although there are other developers that are more
> qualified to comment on that).
> Josef Söntgen
> Genode Labs
> http://www.genode-labs.com/ · http://genode.org/
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users