Subject: Re: device attachement detection from userland
To: Jachym Holecek <freza@dspfpga.com>
From: Matthias Drochner <M.Drochner@fz-juelich.de>
List: tech-kern
Date: 11/07/2006 19:11:02
freza@dspfpga.com said:
> Things are somewhat complicated by the way our autoconf(9) currently
> works. Among other things, "device_t" == "device _and_ driver".

I don't think it is that bad. device_t is the data needed
for an individual device, which is partly generic and partly
driver specific. The driver itself, which is everything common
for a device type, is cfdriver_t/cfattach_t. And there is
something which connects individual devices to drivers,
which is cfdata_t. Imho the general structure is fine.
We need to organize data in the attach args better to seperate
bus "addresses" (which are of less use with modern busses like
PCI, almost useless with cable buses like USB and completely
pointless with eg bluetooth) from device type and instance
specific data. For that, we still need to clean up some
creative abuse where the same attach args are used in different
contexts, with one or more members used as selectors.

> it seems reasonable
> to limit devmon to cover case (b) for now

Yes, I think so too. It would be sufficient for "hal" which
is more important than automatic driver loading imo.

> The API can just announce
> attach/detach of driver instances

Yes, in principle it just needs to tell the device name and
perhaps some type (like d_type) for a coarse filter. The rest
can be done by drvctl ioctls.
Actually, I had added hooks into the autoconf framework and
extended drvctl(4) to provide a "monitor" minor device a while
ago, but I didn't have time to keep up with all the proplib
changes so that it isn't usable right now.

> > 3) Something identifying a device instance, sometimes called "Vital
> >    Product Data", should be bus independant.
> I'm not sure what you mean by (3), can you give an example?

This is device serial number, or ethernet address, or disk slice GUID.
Whatever is available to indentify a single device from the hardware POV,
so that it can be bound to a logical instance at kernel level or by
a user daemon. "bus independant" should mean that it should not
matter whether I connect eg a disk by USB or firewire.

best regards
Matthias