xorg-server/*bsd: moving from hal support to devd support?

[Guillem Jover]

Hi all!

On Tue, 2011-02-15 at 17:28:55 +0100, Cyril Brulebois wrote:
> Warner Losh <imp at 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