Hi Cedric,
thank you for sharing your concerns and consulting us for the best course of action.
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.
The driver_manager was a pragmatic stepping stone for Sculpt OS that we introduced in Sculpt EA [1] before the first version of the sculpt_manager existed.
[1] https://genode.org/documentation/articles/sculpt-ea
It served us reasonably well over the years but Sculpt OS has evidently outgrown it by now. From Sculpt's perspective, the distinction between the driver_manager and sculpt_manager serves no longer a purpose but stands in the way.
For example, with the multi-head support planned for later this year, the RAM needed by Intel FB depends on the number of connected displays and their resolutions. To account for that, we would need to assign a huge amount of RAM quota to the drivers subsystem, planning for the worst case. Still, the static limit might not be enough. In contrast, by hosting Intel FB in the runtime subsystem controlled by the Sculpt manager, we can assign and upgrade the RAM quota of the driver on demand.
For USB handling, the sculpt_manager already did part of the job, but had to coordinate with the driver_manager. The merge removes this bureaucracy.
For suspend/resume, we need to orchestrate the starting, stopping, noticing, and monitoring of drivers depending on the various stages of the system. The Sculpt manager is in charge of driving these stages. So it is natural to let it manage the lifetime of the drivers directly.
In short, the merge of both management components is consequential from Sculpt's perspective, anticipating the items on our road map.
In your case where you don't want to inherit Sculpt's user experience, I see three possible routes to take.
1. You keep a custom version of the driver manager according to your needs. Given that we are speaking of a single file of less than 500 SLOC, I think this is quite reasonable.
2. I try hard to organize the code of the sculpt_manager in a way that keeps concerns separate. The driver-managing code implementing the logic that formerly resided in the driver_manager will go into separate header files. You could try creating a new driver manager using these sculpt-manager internal headers. If this works out well, we could even think about moving these parts to some public include path in the future. A custom driver manager based on these utilities will automatically benefit from our future refinements.
So you can make use of some guts of the sculpt_manager for implementing your driver manager that fits your needs best.
3. You could contemplate using Sculpt OS in a headless way. So your system would be a Sculpt system under the hood (using the concepts of the config fs and report fs as well as the sculpt_manager) but without any UI portions of Sculpt. Should you be interested in this direction, I could introduce a config attribute for operating the sculpt manager in headless mode.
This direction has the appeal that the Sculpt system is already tuned in useful ways. For example, the new audio infrastructure will depend on good timing, which requires the careful assignment of scheduling parameters (i.e., priorities). Otherwise, one could end up with bad quality (like grinding artifacts). For Sculpt OS, we make it our mission to find parameters that work well for a variety of work loads. By basing your system on a bare-bones version of Sculpt, you would immediately benefit from this work. And Sculpt would benefit from your feedback. ;-)
For the start, I'd probably pick route (1). Once the new version of Sculpt is ready, you could give route (2) a try. Route (3) would make sense if you aspire to foster the interoperability between your system and Sculpt OS.
Cheers Norman