Hi Michal,
I was also thinking about this problem and my idea was not to create a
separate new entity 'unit', but to extend the existing HelenOS concept of
service (I think MD suggested something similar some time back).
My idea stems from trying to solve the problem described by http://trac.
helenos.org/ticket/184
When you are connecting to a service, you want the system to:
- give you an error if the service is disabled or failed to start
- succeed if the service is started
- possibly attempt to start the service automatically and give you control
back when the service is up
One could extend locsrv to be the service manager. You could have a list of
'registered' servers that it could start and track their running state. As
part of server metadata we could have a static list of service(s) the server
provides (not necessarily all services that the server provides!). Thus we
could resolve that in order to make service X available, we need to start
service Y.
Similar to your concept, then it would not be necessary for, e.g., devman to
manage lifecycle of drivers, a driver would be just a registered server that
would declare one special service (e.g. drv/<driver_name>). Devman would
just connect to this service in order to load a driver (problem: how to
determine a particular driver does not exist?)
In the cases where some other entity than an actual service would be needed
(e.g. mounted filesystem), this could be solved by representing it by some
(possibly dummy) service.
As far as dependencies go, I think one of the weakest points of systems such
as SMF is that their dependency tracking is too coarse-grained. In effect
service A either depends on service B or doesn't. If it does, service B must
come completely online before A can start. At the same time 'services' are
large, mostly static things, like 'all filesystems are mounted' or 'network
is configured'. With things like iSCSI you get circular dependencies very
quickly (which are prohibited!)
With implicit dependencies (and blocking behavior) we can just let
networking and filesystem services start at the same time and let
dependencies resolve themselves implicitly. (E.g. root filesystem is
mounted, but network filesystem is blocked because it's waiting on
networking. Networking successfully reads configuration from root
filesystem, then it comes up - then network filesystem is mounted). This way
it works even if we don't have a separate service for network filesystem, as
long as mounting one fs does not block waiting for mounting of another, non-
related, filesystem.
Regards,
Jiri
---------- Původní zpráva ----------
Od: Michal Koutný <[email protected]>
Komu: HelenOS development mailing list <[email protected]>
Datum: 12. 2. 2015 21:11:56
Předmět: [HelenOS-devel] System daemon progress
"Greetings.
I've been thinking about some design issues of the system daemon and
compiled my contemplations into a ticket update [1]. There are some
suggestions and indirect questions. I'd be glad if you could provide
me with some comments or answers to these.
Thank you,
Michal
[1] http://trac.helenos.org/ticket/525#comment:5
_______________________________________________
HelenOS-devel mailing list
[email protected]
http://lists.modry.cz/listinfo/helenos-devel";
_______________________________________________
HelenOS-devel mailing list
[email protected]
http://lists.modry.cz/listinfo/helenos-devel
