On Sun, Jul 25, 2010 at 05:54:01PM -0400, der Mouse wrote: > > 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. It seems to me that scsibus serves a different purpose, but yes, it is surely possible to achieve similar results using the current autoconf(9) and probably abusing it in various ways. > > 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). The interaction between zs and zstty looks to me like plain regular direct configuration, with zs enumerating features. > 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. It has to know the features (and yes, calling them devices would be somewhat incorrect) exist, even if it doesn't know their purpose. > But I feel certain you are already familiar with all that. So I must > be missing something. What? My explanations are certainly most unclear; I think the point of the flavours is to add a bit of indirect configuration over a direct configuration bus. The way I understand zs(4) works, the zs device serves as an enumerator of a list of features. The intended purpose of the flavours is indeed to push that kind of behaviour back into the configuration framework. Now, I don't think they're entirely swapable, especially not in the example I give. Part of the difference between zs(4) and the pcib(4) case is that in the former case, the features are not terribly different from one another, or at least not different enough to warrant a different interface attribute. In the pcib(4) case, the features are logically at complete odds, and having them as children enumerated by a "controller" pcib driver would mean pushing a lot of knowledge about they work into said controller driver. With the flavours, pcib(4) doesn't have to do anything but attach the isa(4) bus. Does that clear things a little? -- 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:
pgph85WaUaLSR.pgp
Description: PGP signature