From owner-freebsd-x11@FreeBSD.ORG Wed Feb 16 04:34:17 2011 Return-Path: Delivered-To: freebsd-x11@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC6E0106566C; Wed, 16 Feb 2011 04:34:17 +0000 (UTC) (envelope-from guillemj@ono.com) Received: from resmaa12.ono.com (smtp12.ono.com [62.42.230.20]) by mx1.freebsd.org (Postfix) with ESMTP id 741FB8FC08; Wed, 16 Feb 2011 04:34:17 +0000 (UTC) Received: from gaara.hadrons.org (85.136.146.198) by resmaa12.ono.com (8.5.113) (authenticated as guillemj@ono.com) id 4D301C970052AB02; Wed, 16 Feb 2011 04:46:15 +0100 Received: from guillem by gaara.hadrons.org with local (Exim 4.72) (envelope-from ) id 1PpYuE-000711-4E; Wed, 16 Feb 2011 05:22:22 +0100 Date: Wed, 16 Feb 2011 05:22:21 +0100 From: Guillem Jover To: Cyril Brulebois Message-ID: <20110216042221.GA26233@gaara.hadrons.org> Mail-Followup-To: Cyril Brulebois , Warner Losh , miwi@FreeBSD.org, freebsd-x11@FreeBSD.org, xorg-devel@lists.x.org, debian-bsd@lists.debian.org, Warner Losh References: <20110213124019.GH7840@debian.org> <4D596ECB.8080404@bsdimp.com> <20110215162855.GR15960@debian.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110215162855.GR15960@debian.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-x11@FreeBSD.org, miwi@FreeBSD.org, xorg-devel@lists.x.org, debian-bsd@lists.debian.org, Warner Losh , Warner Losh Subject: Re: xorg-server/*bsd: moving from hal support to devd support? X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 04:34:18 -0000 Hi all! On Tue, 2011-02-15 at 17:28:55 +0100, Cyril Brulebois wrote: > Warner Losh (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