Martin Decky wrote: > Well, in my humble opinion changing the location service to support > multiple callbacks and introducing synchronous driver startup into > devman are more or less equally complicated tasks (from the programmer's > point of view). When I think about it, the former might be even a little > bit easier to implement than the latter, given all the corner cases that > need to be considered. > > The first option seems to be a proper and long-term solution for the > problem, while the second option seems to be just a temporary hack with > no other benefits. Why not simply implement the first option then?
Jiri Svoboda wrote: > What actual problem are you trying to solve? > > First of all, clients don't know anything about devman or drivers, they just > know about services. If your client depends on a particular service, it can > connect to it in blocking mode (i.e. wait for it to become available) or > connect to it when it becomes available. If your client connects to all > services in a category, for example, it can simply connect to them as they > become available. Currently there is no problem, because I can work around it when starting console server - it needs just a single screen, so during init routine it is sufficient to poll a category until there is at least one screen available. The other way around would be to hardwire screen name into init routine and connect to it in blocking mode. However, when I get to implementing a compositor server, I will need to use the same pattern as is currently used in the reworked input - i.e. location service will notify compositor about new screens via callback. I feel that problem is solved for the time being. I just wanted to make sure what the proper solution is and whether the single system-wide callback is merely a temporary solution or a serious design limitation. Thanks for clearing that up. Petr _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
