Fellow Genodians, regarding ticket 5150 : Consolidation of the driver manager into the sculpt manager ( https://github.com/genodelabs/genode/issues/5150 )
I'm in the process of integrating driver_manager into my h/o/g project, to give it basic dynamic drivers ability (it previously hardcoded Vesa video etc). After peeking at ticket 5150, I looked into sculpt_manager, wondering if I could make a bigger "jump" and migrate directly to that component, but that does not seem compatible with my goals (sculpt_manager embodies much of the SculptOS "feel" and would conflict with my h/o/g goals). So it seems like I'll need to preserve a copy of driver_manager before it is deprecated/retired, make it an (ex)Genode component in the h/o/g repository.
Still, thought I'd better post my reasoning here in case someone finds fault with it : from where I stand, that seems to be the natural way to go, and it seems to have few dependancies so I assume the (verbatim "forked") driver_manager will keep working in future Genode releases. I'll just need to mirror changes that occur in Genode when a driver (intel_fb etc) is modified in terms of how it's ran, what arguments are passed to it.
Cedric