Re: autoconf question

[Paul Goyette <paul%whooppee.com@localhost>]

On Fri, 4 Jul 2008, Quentin Garnier wrote:

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

OK, that seems reasonable.

> 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 :-)

:)

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

However it's quite conceivable that sdmmc devices might well be able to 
attach via other hardware than sdhc.  Indeed, that other hardware might 
not even be PCI-based.  In this case, the specific card sdhc provides an 
abstracted interface to the sdmmc device.  Using an sdmmcbus for this 
interface seemed reasonable.  But you're right, it really doesn't add 
any functionality and could easily be removed.

(As a side note, this driver was originally developed for OpenBSD, and 
was ported to NetBSD by Nonaka Kimihiro.  There was some objection back 
in March about using a scsipi abstraction for the memory cards, and a 
suggestion to move it to using the ld(4) interface.)

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

So in this case I would have (possibly)

        device sdmmc { } : sdmmc_io sdmmc_mem
        ...
        attach ld at sdmmc_mem with ld_sdmmc
        ...
        device othercard at sdmmc_io

This way there's two separate interfaces offered by sdmmc, and one of 
those (sdmmc_mem) is another option for ld to use.

Does this look more sane?

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

In the case of "Combo" cards, the card offers multiple functions, but 
the "memory" function can show up anywhere, or everywhere.  It can be 
"piggy back" on an othercard or it could have its own function.


----------------------------------------------------------------------
|   Paul Goyette   | PGP DSS Key fingerprint: |  E-mail addresses:   |
| Customer Service | FA29 0E3B 35AF E8AE 6651 |  paul%whooppee.com@localhost   |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette%juniper.net@localhost |
----------------------------------------------------------------------