tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: RFC: device flavours

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 - -
"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

Home | Main Index | Thread Index | Old Index