Hi Warner, Warner Losh <i...@bsdimp.com> (14/02/2011): > I'm mentioned this several times now: Get me a spec for what Linux > udev provides, and what services are needed, and I'll make a > compatible implementation on FreeBSD.
as far as X is concerned, see Dan's reply to my first mail: http://lists.debian.org/debian-bsd/2011/02/msg00120.html I think we really don't care how udev works, we just need to gather: - devices available when X starts, - devices updated while X is running. What follows was performed on a GNU/kFreeBSD system in QEMU. For now, I tried to print all variables mentioned in devd.conf(5), and used “usb_add mouse”/“usb_del 0.2” in the QEMU console (adding/removing an USB mouse). That notified me about ugen0.2 getting ATTACHED and DETACHED. Since I'm pretty unfamiliar with FreeBSD, I couldn't link that to the according /dev/ums0 being created/deleted. Since I wanted to try and play with hotplug anyway, I wrote a tiny daemon to perform input bookkeeping (inputbk), which does: - list all devices through libdevinfo which seem to be input devices (for now I matched on the drivername, being one of: atkbd, psm, ukbd, ums; uhci should probably be added, but I coudln't check myself); - sleep one second (which could easily be replaced with waiting for a devd ATTACH/DETACH event); - list all devices again, and print added/deleted devices. Then in the xorg-server sources, I started a config/inputkb.c file, and added a device based on the information I printed from the inputbk daemon (which I hardcoded to check quickly how it went), which gave me X working without configuration, and without hal. Now, I'm wondering where to go from here. Given what I wrote up to now, my next move to check hotplug works properly: - make inputbk perform a blocking open on a fifo for writing, - make it wait for a reader to write a listing of devices, - then make it loop and only write updates there. On the X side, we would be doing: - read the initial listing, adding devices as appropriate, - add this fifo to the big select() of X, using a callback which would trigger device addition/removal as notified through the socket by inputbk. In a perfect world, we should be able to have several readers, since we might have some X instances running in parallel, so the named pipe approach is probably a bad idea (then, using a socket and adding a few lines of code would buy a daemon handling several clients). Also, I'd be happy to see the above-mentioned bookkeeping go in some other place. AFAICT, devd is appropriate for change notifications, but I'm not sure its purpose is also to keep a list of available devices. What do you think? KiBi.
signature.asc
Description: Digital signature
