Hi, while merging recent mainline changes (including reworked input drivers) into gui branch, I made some troubling discoveries about the way me and Jan choose to initialize DDF input/output drivers. It seems we both decided to register a category change callback to the location service and then to let drivers register themselves into categories (which triggers the callback). Personally, I think it would be better to request devman to initialize certain drivers synchronously and then simply fetch them from location service categories - however this is currently not possible as devman is launching all drivers asynchronously. Anyway, back to the encountered problems with the callback solution.
First of all, location service currently supports just a single callback for the entire system and once it is registered it cannot be changed or unregistered. That means when some process registers a callback, nobody else can use this feature of location service. Secondly, registering a callback alone is not enough to safely discover all drivers - because devman is launched very early in the init routine, it is possible that all drivers initialize themselves before some other process (e.g. input server) even registers the callback to discover the drivers. One must either make sure that the callback registrator is listening before any driver is executed (which might not be always possible) or some sort of polling of location service categories must be employed (either polling alone or polling combined with category change callback to decrease latency). Note that currently in mainline, input server (who registers the callback) is spawned later than devman and does not use any polling, so there is a potential for race condition. To sum up, some technical improvements to the current implementation have to be done - either synchronous driver initialization in the devman or support for more than one category change callback in the loc. Also, the input server should employ polling in addition to category change callback (at least until proper solution is discovered). Regarding the recent changes to input server, I also encountered very peculiar race condition which is probably unrelated to the potential race condition mentioned above. The callback cat_change_cb() inside input.c currently checks both keyboard and mouse categories for new drivers. Therefore, both keyboard and mouse driver should be either discovered together in the first callback caused by any of them, or in two different callbacks. Apparently, it sometimes happens that input server discovers keyboard driver but not the mouse driver (which is although running and emitting events). I encountered it only on the gui branch after merging mainline and not on the mainline itself - however I doubt it is caused by anything inside gui branch and suspect somebody will sooner or later encounter it also on the mainline. I briefly tried to analyze it, but any addition of printf to the cat_change_cb() cause the problem to disappear. Although I am not sure, it seems there is some sort of race between input server reacting to the first callback caused by keyboard driver and mouse driver registering itself into location service category. Petr _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
