Re: RFC: device flavours

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> 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                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B