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

it may be, but there are even some drawbacks from a user's standpoint.
For instance, if a user wants to know what busses are supported by a
given device, that's relatively hard to figure out, etc.


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

You're thinking about doing it the wrong way.

what you'd do, is define an attribute (say, aic7xxx), then have
aic7xxx.c included when the attribute is needed, then have the bus
drivers require that attribute.


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

sure, that can be done.  E.g. it's done with the MI TurboChannel LANCE
driver.

The problem with it is that it means that the 'files' file that
defines the 'ahc' device needs to know the definitions for all busses
that the 'ahc' can attach to.

This causes several problems/annoyances:
	(1) all of the busses must be defined when the device is
	    defined, so machines without, say, EISA busses will
	    _always_ require that EISA be defined,
	(2) it requires each of the busses to be declared "needs-flag"
	    where that may otherwise be unnecessary.

When you're talking about a device like 'if_le', which can live on
just about any bus on any machine, it becomes really problematic to do
things this way.  The reason why i bring if_le up, is because there's
a TurboChannel version and an ISA version, both of which could be
usable on Alphas (and both of which _should_ be usable on alphas, and
both of which have been sold by DEC with alpha systems!).  A similar
problem will be run into on sparcs when PCI sparcs start showing up,
because there'll be the SBUS version and random PCI (and maybe
ISA/EISA) versions...  In the long run, it means that unless drivers
are split up by bus, there'll end up being one uber-driver for the
LANCE, which will need to know about most of the busses supported by
most of the modern systems that NetBSD supports...


chris