After few glitches I've managed successfully boot Sculpt to the point where Leitzentrale console is working. It's interactive nature is really cool and makes me want to play with it further.
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.
Additionally I can see that usb storage devices are properly detected and reported so alternatively I could use a pendrive as storage for genode data.
I think there are two possibilities to continue.
First is to change Sculpt configuration during preparing image to match my configuration.
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'd like to try to work a little to make a second solution working (although probably I'll have to make the first (static) version working before making a dynamic one).
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.
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).
I think you already have some vision how you plan to implement that part of system. Do you plan to extend driver manager implementation? Would such work be a good contribution? Or maybe you plan to reimplement this functionality in a less low level language? Nim?
Tomasz Gajewski
Hello Tomasz,
thanks for the feedback!
* Tomasz Gajewski <tomga@...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
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@...1...> wrote:
Hello Tomasz,
thanks for the feedback!
- Tomasz Gajewski <tomga@...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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Josef Söntgen <josef.soentgen@...1...> writes:
Hello Tomasz,
thanks for the feedback!
- Tomasz Gajewski <tomga@...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.
Can you share your configuration or is it already available somewhere? It would be easier to understand and modify working configuration instead of experimenting with part_blk examples.
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.
I didn't want to suggest a place for this functionality but in my opinion as a new user it is crucial to allow new people to come to project. Currently this step is hard to overcome. You have to have one drive and format it whole for Genode or you have to be a Genode expert to go on further (or ask for an example :-) ).
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.
It's a complex topic and it's hard for to write good questions for this. Sculpt as step of scenario prepares disk for later usage with Genode. That's why I think about it a little like with an installer where I can point it to some partition instead of using whole disk. And this step should not be performed with rebuilding a scenario - it should be available after running it and done in as easy as possible steps. And ideally after doing this once it could be later autodetected as Genode partition and used automatically the second time I start Sculpt.
From what I know about the project all required elements are available
to make it possible. I'd like to try to make it possible and I'm asking if you have some ideas about how this could be achieved. driver_manager is the part that I found that generates dynamically configuration for drivers depending on detected hardware and that's why I proposed extending it. Maybe it should be a different component.
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.
Ok, so for now I'm thinking only about "system" disk/partition for Genode.
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).
I'd like to hear about your, Genode, vision for this. I understand it is complex. Drivers are needed to have storage. Storage is needed to have drivers - at least some of them. And generally devices autodetection and management is complex.
Tomasz Gajewski
PS. I don't know why sourceforge doesn't like my emails today. I've sent original one 4 times and 3 times it was not accepted with 550 and congratulations about some points my mail received (number was changing even though mail was exactly the same) and 4th attempt was marked as spam. I asked sourceforge about it and I hope they will respond.
-
Josef Söntgen -
Nobody III -
Tomasz Gajewski