Hi Petr, Petr Koupy wrote: > 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). That's the correct way to do it. That's how the system is designed to work.
> Personally, > I think it would be better to request devman to initialize certain drivers > synchronously and then simply fetch them from location service categories - I don't understand what you mean. > however this is currently not possible as devman is launching all drivers > asynchronously. Anyway, back to the encountered problems with the callback > solution. I still don't follow. > 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. Currently only one task can register only one callback, not more. But that's just because it wasn't needed yet, so it wasn't implemented. Now it's needed, so it should be implemented. It's a simple and straightforward thing to do. > 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. No. Look at the code in input server and you will see it works perfectly. When input server starts it: 1. registers a change notification callback 2. scans the desired categories (kbd and mouse) 3. whenever the categories change, the callback is invoked and the categories are re-scanned So, any services registered before the start of the server are discovered during step 1. .... > 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. That's really strange. Let me know if you find out more. Cheers, Jiri _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
