Hi all, I'm looking for comments about what I call "device flavours". The best example of the kind of situation it tries to be an answer for is the multiplicity of drivers one can find around the source tree for PCI-ISA bridges (mostly on x86). An even older idea of mine is to finally see legacy devices listed in the ACPI tables attached to the PCI-ISA bridge where they logically belong, and device flavours can be used for that, too. Here's an exerpt of the dmesg output I get on my EeeBox, with two flavours defined, ichlpc (to replace ichlpcib(4)) and acpiib (to let legacy devices attach there; I've only let npx(4) attach though for the sake of the test): pcib0 at pci0 dev 31 function 0: vendor 0x8086 product 0x27b9 (rev. 0x02) timecounter: Timecounter "pcib0/ichlpc" frequency 3579545 Hz quality 1000 pcib0/ichlpc: 24-bit timer pcib0/ichlpc: TCO (watchdog) timer configured. gpio5 at pcib0: 64 pins pcib0/acpiib: ACPI node SBRG npx1 at pcib0 (COPR, PNP0C04): io 0xf0-0xff irq 13 npx1: reported by CPUID; using exception 16 SIOR (PNP0C02) at pcib0 not configured RMSC (PNP0C02) at pcib0 not configured OMSC (PNP0C02) at pcib0 not configured A device flavour is essentially an incomplete device driver. That means it will never be active unless a driver has already attached to a device. But the main point is that a flavour can be created without the main driver being aware of it; additionally, a flavour gets its own device_t and thus can interact on its own with any subsystem that uses device_t, mostly pmf(9). (And, as you can see in the example, aprint_*_dev functions.) On the config(5) side, a device flavour is defined as something that attaches to an interface attribute. The reason for that is of course that there is no need for it to assume the name of the main driver to function properly. So, in my files.* I have defined the following: flavour acpiib at pci: acpinodebus file dev/acpi/acpiib.c acpiib flavour ichlpc at pci: acpipmtimer, sysmon_wdog, fwhichbus, hpetichbus, gpiobus file arch/x86/pci/ichlpc.c ichlpc And then in my kernel config file I added the following: flavours ichlpc, acpiib npx* at pcib? gpio* at gpiobus? (The last two lines are there only to explain the attachments in the example.) At run time, I am only going to describe what happens at attachment time, because I haven't done anything about detach yet. When a device is *found* (i.e., once its device_t has been created and linked) using the interface attribute "pci", the match functions of all flavours of the pci interface attribute are called, and for each that returns non-zero, a device_t object is created using the name "device/flavour" and add to the "parent" device_t's list of flavours. Then when what is really a sibling driver is attached, a call is made the the flavour's callback. In my proof-of-concept code I added a call right before the main driver is attached, and another one right after, because there might be situations where either is needed (and typically for a flavour that enumerates children, it might prefer doing it before the main driver gets a chance to do it). For reference, my current patch: http://taryn.cubidou.net/~cube/flavours.diff Again, it is a proof of concept; detaching is not handled, so the kernel will fail to reboot, and there is no locking whatsoever, so Bad Things could happen. There are other situations in which I think device flavours could bring clarity and also better modularisation. For instance, support for CPU features on x86 like EST or PowerNow, or even ACPI P-states could be done that way, and it is more module-friendly because it wouldn't require the main CPU driver to explicitely call those feature-drivers. I've been wondering about simply allowing more than one driver to attach to a device, and while this might be a lot simpler as far as config(1) and even autoconf(9) are concerned, it raises other issues, like how to deal with device_t's. One thing I'd like to get input on anyway is how to actually deal with pmf(9). I haven't looked at it at all yet, but I don't really expect miracles for my current patch. -- Quentin Garnier - cube%cubidou.net@localhost - cube%NetBSD.org@localhost "See the look on my face from staying too long in one place [...] every time the morning breaks I know I'm closer to falling" KT Tunstall, Saving My Face, Drastic Fantastic, 2007.
Attachment:
pgpQ0HqQ8ZCMG.pgp
Description: PGP signature