--+HaDSJYnsYzHewVa
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Nov 01, 2006 at 01:06:15PM +0100, Jachym Holecek wrote:
> # Matthias Drochner 2006-11-01:
> > thorpej@shagadelic.org said:
> > > > I think with current state of autoconf(9) the code is fairly OK. We=
'd
> > > > need to move relevant members of <foo>_attach_args to locators and =
=20
> > > > maybe
> > > > replace cf_loc with property lists to get somewhat better.=20
> > > > [...]
> > > We now have plists, and should use them
> >=20
> > 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.
> >=20
> > 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".
>=20
> Things are somewhat complicated by the way our autoconf(9) currently
> works. Among other things, "device_t" =3D=3D "device _and_ driver". I thi=
nk
> 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
> feature).
>=20
> After autoconf(9) gets some treatment, handling case (a) would just
> mean adding a new event type ("device", as opposed to "driver").
>=20
> (Other then my point of view being strongly devmon-centric, I think
> I agree with what you say on how things should work.)
>=20
> > 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 [1] 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.

[1] http://mail-index.netbsd.org/tech-kern/2005/11/11/0011.html

--=20
Quentin Garnier - cube@cubidou.net - 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.

--+HaDSJYnsYzHewVa
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (NetBSD)

iQEVAwUBRUihVtgoQloHrPnoAQJ8dQf/Z5ma7cLnFFmQsSztv6jKyg5chjZPdX2a
E3qy8n0tcw6Ld7wSzh4FkuVICL/n+Vvv1MazlwWxSteEFzO7BNNCv9LkTPUjxp3i
pI/LPJ+u1akjww4hGKjXcOf0TgmxJ72Fl/P05Se8MZ2L73w1wza/7Jaa/gCNaw4Q
iidxHJnzhoxYX+T+8eSV8h7n2fcwDCSamW39e48HF6hRXuJ2FKCnP1o5iIVgtIR8
LSx1HfKt9PNb2UWLZn9xCFiNBKeJjiyl4gRsv0vXyhTXQz/3G5uBSK0o35L04ftA
b/g7sRxAMFSnCjTqFQ0zRIPPBCGrhTnasmEjf1++sB8ow9qoZjJcjQ==
=7zfd
-----END PGP SIGNATURE-----

--+HaDSJYnsYzHewVa--