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
--
Dr.-Ing. Norman Feske
Genode Labs
https://www.genode-labs.com · https://genode.org
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
___
users mailing list -- users@lists.genode.org
To unsubscribe send an email to users-le...@lists.genode.org
Archived at
https://lists.genode.org/mailman3/hyperkitty/list/users@lists.genode.org/message/O7CHBRXB6RH63ZBIXKDEL2ROQALPUXLT/
