On Thu, Jul 03, 2008 at 07:57:32PM -0700, Paul Goyette wrote:
> On Fri, 4 Jul 2008, Quentin Garnier wrote:
>
>>> That's what the attach args (aux) are for. Have the parent enough
>>
>> That and the interface attribute (the ia in the API). If there are
>> two classes of child devices, that begs for different interface
>> attributes. Please don't abuse the attach args for that.
>
> Hmmm. Based on the docs available, I was under the impression that
> interface attributes were for the child to be able to attach to different
> parents. Such as the ld(4) driver attaching to all sorts of RAID
Think of it in hardware terms. Say the parent device is a computer:
you can plug a USB mouse, or maybe a USB key, and a firewire video
camera. Two obvious interface attributes there.
On the other hand, an external drive can connect by USB and firewire,
or even a mouse can be USB or PS/2. So interface attributes work both
ways.
> controllers. In fact, one of the children of my driver is yet another
> (non-RAID) interface for ld.
The ld example really is a good example, because it's not "a" driver.
It's a lot of different drivers offering a common interface to userland
and the kernel to some extent. I.e., for the user, a mouse is a mouse,
but from an engineering point of view, a ps/2 device has nothing to do
with a USB device.
Ah, darn it, I should find an analogy involving cars. People would get
it then :-)
> So what I've got is
>
> device sdhc: sdmmcbus
> attach sdhc at pci with sdhc_pci
> file . . . .
>
> device sdmmc { }
> attach sdmmc at sdmmcbus
> file . . . .
>
> attach ld at sdmmc with ld_sdmmc
> file .../ld_sdmmc.c
>
> device flashcard at sdmmc
> file ...
>
> When an instance of sdmmc attaches to the sdmmcbus (ie, a card is
> inserted), I want to attach an ld and a card-specific I/O driver for each
> "function" offered by the card. The configuration process seems only to
> evaluate the match of all possible children and picks the best one.
Interestingly enough, you explicitely define an interface attribute
(sdmmcbus) when you don't necessarily have to (because only sdmmc-like
devices will attach to sdhc), and you don't when you really mean to.
> Since I need to have _two_ children, I can run config_match*() twice, but I
> need to have the ld driver get selected the first time, and the other
> driver selected on the second call.
If you have 2 devices, you need to call config_found_ia() twice (and
make sure you have the APIs). In this case you want two different IAs
because they are very different devices to which you won't pass the same
information. It should never be the responsibility of the child device
to decide whether its match function was called rightfully or not.
Reading your questions though, and considering I know nothing of the
SDHC spec, I wonder if the ld device belongs where you put it in your
scheme. Do the cards always provide a mass-storage interface? Or is it
just another interface among other possible ones? In the latter case,
you'd need another device to be the parent of the ld, so that all
functions of the card are equals and enumerated without specific cases
by the sdmmc device.
--
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:
pgpTMKNLSj0KH.pgp
Description: PGP signature