>> This brings up yet another point.  Where should a driver which supports
>> more than one bus (pci, isa, and eisa) go?  It doesn't fit anywhere
>> really.
>
>My answer to this is "dev/ic," but it should include no bus-specific
>code.  bus-specific adapter drivers should be in the appropriate
>directory, and should be differently named.

I don't quite agree, but I don't quite disagree either.

The ability to have one ahc (for example) which will attach any of the
aha2[789]4x cards as well as aic7[78]70 generic motherboard chips is a
much nicer way to look at the world from a user's standpoint.

>Compared to that, "dev/ic" and "dev/<bus>" seems ... very attractive.

Well, there are some ``gotchas'' right now in this scheme, and that is
that dev/ic doesn't have a files.ic file.  Should it?  Is the config
program smart enough to see two lines like
	file   dev/ic/aic7xxx.c		ahc
and
	file   dev/ic/aic7xxx.c		ahe
in two different files?  (I admit I've not tried this.  The change I
made was to add ahe in the files.pci file for now.  Not a good
solution, but it was quick.)

I tend to think that, if all that needs to be done to a card is to
identify the exact model and bus it is on, then call a common set of
MI functions to talk to the chip on the card, having one device on all
possible busses isn't a bad decision.  The structure of the driver for
ahc could be:

#if NISA > 0
	attach the isa card
#endif
#if NEISA > 0
	attach the eisa card
#endif
#ifdef NPCI > 0
	attach the pci card
#endif

and check in the ISA portion to make certain the particular instance
of the driver being checked for has the isa bus as a parent.

This would allow
ahc0	at isa? irq 14 ioaddr 0x1c00
ahc1	at pci?

--Michael

--
Michael Graff <explorer@flame.org>        NetBSD is the way to go!
PGP key on a key-server near you!         Netshade the world!