Date: Wed, 16 Feb 2011 05:22:21 +0100 From: Guillem Jover <guillem@debian.org> To: Cyril Brulebois <kibi@debian.org> Cc: freebsd-x11@FreeBSD.org, miwi@FreeBSD.org, xorg-devel@lists.x.org, debian-bsd@lists.debian.org, Warner Losh <imp@FreeBSD.org>, Warner Losh <imp@bsdimp.com> Subject: Re: xorg-server/*bsd: moving from hal support to devd support? Message-ID: <20110216042221.GA26233@gaara.hadrons.org> In-Reply-To: <20110215162855.GR15960@debian.org> References: <20110213124019.GH7840@debian.org> <AANLkTinARF1Jrz3wg97n0jxMFfqBy16nuayUu3=mDH6w@mail.gmail.com> <4D596ECB.8080404@bsdimp.com> <20110215162855.GR15960@debian.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi all! On Tue, 2011-02-15 at 17:28:55 +0100, Cyril Brulebois wrote: > Warner Losh <imp@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. FWIW, I'd really not try to follow udev on this (or for that matter any of the so called Linux plumbing) given their general stance on portability beyond Linux and usual strong reliance on features from latest Linux versions. What I think would be really nice and helpful, as I mentioned on IRC in #debian-kbsd, would be a shared library to parse the output and handle the events from the devd daemon's client socket, etc, which would avoid having to replicate that logic on each application. If that library could also use as backend OpenBSD hotplugd (I don't think NetBSD devmon got implemented, though), and possibly the Solaris sysevent thingy, that'd be a plus, and would make it even easier to replace the now deprecated 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? I'm not sure why you'd want to have yet another daemon, which seems to be relaying the information devd is already relaying from the kernel, instead of just doing this all in X itself, by querying the initial state through libdevinfo, and then handling hotplug event through the devd client socket (ideally using a shared library for the latter when and if that gets implemented)? thanks, guillem
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110216042221.GA26233>