Subject: Re: device attachement detection from userland
To: Jachym Holecek <firstname.lastname@example.org>
From: Quentin Garnier <email@example.com>
Date: 11/01/2006 14:29:58
Content-Type: text/plain; charset=us-ascii
On Wed, Nov 01, 2006 at 01:06:15PM +0100, Jachym Holecek wrote:
> # Matthias Drochner 2006-11-01:
> > firstname.lastname@example.org said:
> > > > I think with current state of autoconf(9) the code is fairly OK. We=
> > > > need to move relevant members of <foo>_attach_args to locators and =
> > > > maybe
> > > > replace cf_loc with property lists to get somewhat better.=20
> > > > [...]
> > > We now have plists, and should use them
> > I'd say things are more complex than just converting attach args.
> > If we start with a new interface here, we should try to get the
> > structure right and keep as much abstraction as possible.
> > There are (at least) two different interactions with userland we
> > need to consider:
> > a) A device is plugged in, the bus is either able to detect this
> > or a "rescan"-like ioctl was invoked, but there is no applicable
> > driver present in the kernel. This is to demand-load a driver
> > module. Less interesting for general userland programs, in
> > particular "hal".
> > b) A new driver instance was attached, either through (a), or just
> > because a new driver was loaded. This is what is interesting for
> > userland programs, in particular "hal".
> Things are somewhat complicated by the way our autoconf(9) currently
> works. Among other things, "device_t" =3D=3D "device _and_ driver". I thi=
> this should change, but won't have time to work on it anytime soon.
I've been doing some work in that area for some time. I have started
writing down some ideas, but it takes time and I don't have much to
spend on it.
One thing I'm sure of: splitting struct device from softc is a bitch,
but it's doable, although it took me several hours just for the kernel
of my laptop.
As a side-effect, I have wscons's mux "almost-device" in my radar,
because the split is easy as long as drivers respect autoconf(9) API.
> So, thinking about this (and the rest of your mail), it seems reasonable
> to limit devmon to cover case (b) for now. The API can just announce
> attach/detach of driver instances, and probably provide a set of ioctls
> to query device (as in "the device rtk0 driver instance is attached to")
> for additional information (this would be needed at least for hierarchical
> matches the original implementation supported, and I think it was a neat
> After autoconf(9) gets some treatment, handling case (a) would just
> mean adding a new event type ("device", as opposed to "driver").
> (Other then my point of view being strongly devmon-centric, I think
> I agree with what you say on how things should work.)
> > The "attach args" (generalized) consist of:
> > 1) Some vendor/device ID (and class/revision/whatever), telling the
> > type of the device, but not an individual instance.
> > 2) "Locators", telling the address on the parent bus.
> > 3) Something identifying a device instance, sometimes called "Vital
> > Product Data", should be bus independant.
> > 4) Tag/handle and other kernel-internal stuff.
One thing that came out of my experiments in that area is that we really
have to make a difference between direct and indirect configuration. The
autoconf(9) API is not clear enough in that area IMO. The thing is, the
two methods give a rather different meaning to the attach args.
Another thing we currently lack, and for which I still haven't found a
satisfying solution, is a way to make an attachment differ only by a
given property. This is what my config_env  stuff last year was
about, and since then I've been trying to do the same through setting a
property on a device_t object before a driver gets matched for it.
I'll try to summarize my current state of mind and have it through
Jason before I send it to the list.
Quentin Garnier - email@example.com - cube@NetBSD.org
"You could have made it, spitting out benchmarks
Owe it to yourself not to fail"
Amplifico, Spitting Out Benchmarks, Hometakes Vol. 2, 2005.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (NetBSD)
-----END PGP SIGNATURE-----