tech-kern archive

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

Re: autoconf question

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

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 |   |
| Network Engineer | 0786 F758 55DE 53BA 7731 | |

Home | Main Index | Thread Index | Old Index