Jiří, thank you for your insightful answer. 2015-02-13 14:58 GMT+01:00 Jiri Svoboda <[email protected]>: > 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 Is there any fundamental difference between connecting to a service via 'service_connect' (i.e. naming service is the mediator) and 'loc_service_connect' (with location service instead)? In my point of view registering some services at NS seems as historic artifact (e.g. devman, irc, clipboard, udp), especially now when I grasped intended meaning of locsrv.
> 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 > server Y. I don't know whether it wouldn't be better to have service metadata rather than server one. Then we could (besides other things) theoretically cover more complicated start procedures (I imagine service that can be enabled on already running server by passing it (the server) some information.) > > 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?) I think that usually you may attempt to connect to DDF driver service via (preconfigured) knowledge of device tree path or via service ID that you obtained by querying a category (of services). Thus I would let devman to initiate start of driver task. (Eventually, it could be done lazily by extending the tree to match the path.) > > 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. I'm not persuaded that dummy services aren't (over)exploitation of location service as connecting to them seems nonsensical to me (e.g. the mounted filesystem or target). On the other hand, they can provide (together with autostarting) uniform API to satisfy units (where unit denotes an abstraction; services, mounted filesystems and targets are just some things that may be satisfied). ... > 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. Is this mutual blocking issue in HelenOS (vfs)? Provided that 'mount's themselves are called in parallel. Michal _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
