Subject: Re: A possible way of handling variant/common devices
To: Matt Thomas <>
From: Chris G. Demetriou <>
List: tech-kern
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.
> Thoughts?

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


	define	am7990lance
	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
	file ...

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.