tech-kern archive

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

Re: autoconf question

On Thu, Jul 03, 2008 at 09:08:31PM -0700, Paul Goyette wrote:
>> 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.

But leave it in, please :)  That argument works both ways, if soething
else ever expose an sdhc-like interface, things will just work, as you

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

Yes, I remember that.  I was wondering is you were using the same code.

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

That's broken config(5) syntax, but I get the idea.  You want to drop
the {} in the device line if you use interface attributes, to avoid
further confusion.

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

So a function attaching at sdmmc_io could itself expose a sdmmc_mem

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: pgpIWPcBCOmNd.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index