> I'm looking for comments about what I call "device flavours". [...]
I'm having trouble seeing what this offers over things (like scsibus) where an abstraction attaches at real hardware and then other things attach to the abstraction. > flavour acpiib at pci: acpinodebus > file dev/acpi/acpiib.c acpiib > > flavour ichlpc at pci: acpipmtimer, sysmon_wdog, fwhichbus, hpetichbus, gp= > iobus > file arch/x86/pci/ichlpc.c ichlpc > flavours ichlpc, acpiib > npx* at pcib? > gpio* at gpiobus? > I've been wondering about simply allowing more than one driver to > attach to a device, It seems to me that we already have something effectively the same as that, mediated by a "controller" driver. For example, consider the way, on sparc, zs attaches to the chip and then zstty or kbd or ms attaches to zs (or at least that's how it used to work). You write that > But the main point is that a flavour can be created without the main > driver being aware of it; but, again, it looks to me as though we already have that: to return to the zs example, the zs code does not need to know anything about the list "zstty, kbd, ms" in order for those child devices to work. But I feel certain you are already familiar with all that. So I must be missing something. What? /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B