[SPAM] Sculpt scenario and block devices

[Nobody III]

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
default_fs.config.

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...>
wrote:

> 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).
>
>
> Regards,
> Josef
>
> --
> 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
> https://lists.sourceforge.net/lists/listinfo/genode-main
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20180304/03e10b9d/attachment.html>