Subject: Re: A possible way of handling variant/common devices
To: Matt Thomas <email@example.com>
From: Chris G. Demetriou <firstname.lastname@example.org>
Date: 03/28/1997 15:58:32
> I've been wanting to PnP support for a NE2000 clone that Digital
> is now selling. And that has got me to thinking.
> There are a number of drivers (especially on the i386) that need
> to somewhat close variations of cards. Consider the le0 on isa
> for example.
> #le0 at isa? port 0x320 irq 10 drq 7 # IsoLan, NE2100, and DEPCA
> Would it make more sense to have
> depca* at isa?
> depca* at eisa?
> le* at depca?
> And treat the variant as a very thin bus? It would make the config
> file a bit more complicated but it would allow more precise of what
> variants you do need to support.
> This could be applied to the NE2000/WD/SMC driver as well.
So, I'd say that if something like this is desired, a 'better' way to
do it might be:
# LANCE and PCnet Ethernet controllers
device le: arp, ether, ifnet
file dev/ic/am7990.c le
file dev/ic/am7990.c am7990lance
device le: arp, ether, ifnet, am7990lance
file dev/ic/if_le.c le
and move the le_cd definition from am7990.c into if_le.c.
Then, for instance, you could declare you depca driver as:
device depca: arp, ether, ifnet, am7990lance
and define the appropriate attachments, etc.
The am7990 code is already structured in a way that makes this very
easy, and this hides the complexity from the users.
This is only really a problem because the le_cd is included in
am7990.c. For drivers like a common 8390 driver (where there might be
no reason to put the cfdriver into the common code), this really isn't
a problem, and the back-end would just be an attribute, same as for
the ncr5380sbc, pdq, and ncr53c9x drivers.