> Recently the ep entry of files.isa got an pci dependency.
> 
> # 3Com 3C5x9, 3c59x (EtherLink III) family
> device	ep at isa, pci: ether, ifnet, elink
> file	dev/isa/if_ep.c			ep
> 
> I wonder, being no config expert, if this is the only way to do it.

No, and there are more problems than that.

Where shall we begin...  8-)

ISA/EISA/PCI bus providers (in my little world, i call them
"chipsets") should provide attributes called isabus, eisabus,
pcibus, etc.  'isa', 'eisa', and 'pci' should then be attached to those
attributes.

For instance, that leads you to something the following:

in files.isa:

define  isabus { }
define  eisabus { }                     # XXX doesn't really belong here

device  isa at isabus, eisabus {[port = 0], [nports = 0],
                                [sport = 0], [snports = 0],
                                [iomem = 0], [iosiz = 0],
                                [siomem = 0], [siosiz = 0],
                                [irq = -1], [drq = -1],
                                [sirq = -1], [sdrq = -1]}

file    dev/isa/isa.c                   isa     needs-flag


in files.alpha:

device  sio at pci: isabus
device  pceb at pci: eisabus
file    arch/alpha/pci/sio.c            sio pceb        needs-flag
file    arch/alpha/pci/sio_pic.c        sio pceb


and in GENERIC:


# ISA/EISA bus support
isa*    at      pceb?
eisa*   at      pceb?
isa*    at      sio?

# ISA devices
clock0  at      isa? port 0x70
pckbd0  at      isa? port 0x60 irq 1            # PC-ish ISA keyboard
#pms0   at      isa? port 0x60 irq 12           # PS/2 auxiliary
com0    at      isa? port 0x3f8 irq 4           # standard serial ports
com1    at      isa? port 0x2f8 irq 3
lpt0    at      isa? port 0x3bc irq 7           # standard parallel port
#wss0   at      isa? port 0x530 irq 9 drq 0     # Windows Sound System

etc.


the fact that the eisabus attribute is defined in files.isa is so that
'isa' devices can attach to EISA-bus-providing chipsets.  (This could
be handled in a different way, but that's the way I implemented it.)


However, while reorganizing things as such helps some things a lot
(e.g. removes the spec of the 'isa' bus out of MD code, where it
doesn't belong), it doesn't solve all of the problems, including
yours.

There are several thorny problems (including yours) that aren't easily
addressed with the current source tree layout.  they include:

	(1) What do you do with a device that can attach to several
	    similar busses?

	(2) What do you do with two devices named the same thing which
	    do mostly the same things but attach to different busses?

an example of the former is your problem.  One possible solution to it
is to have a core 'back-end' driver that touches the common hardware
and provides a certain attribute, then to have differently-named
bus-specific chunks of code which deal with attaching to the bus, etc.
And example of this is Matt Thomas's FDDI driver which is called "fpa"
on PCI and "fea" on ISA busses.

(2) is, in some ways, another facet of the same problem.  An example is
the problem caused by the use of the machine-independent LANCE code.
There are now _lots_ of chunks of code that deal with bus attachment,
and they're all called if_le.  They're mostly common, but they're all
named the same.  (Additionally, because of the way the MI LANCE code
was structured, they all include the common LANCE .c file!)  Because
of this, one can't safely list "if_le" in the files.isa file list.
(it conflicts with the Amiga if_le, or the Alpha if_le, if those ports
want to include files.isa...)


There's also the (unrelated) problem that (on the i386 port) some PCI
and EISA devices are treated like their ISA cousins, even when that's
unnecessary and (in some ways) broken.  An example of this is PCI and
EISA VGA boards.  PCI and EISA VGA boards are treated by the i386 port
as 'normal' ISA VGAs, even though the bus that they're actually living
on does provide useful information about the device.  In particular,
i'm thinking of the memory mapping registers on PCI VGA boards: they
tell a smart driver exactly what memory should be mappable by the
user, for those boards, and so can allow the kernel to let processes
"safely" map video memory.  This (important, useful) information is
ignored.

There's also the problem that EISA devices just aren't distinguished
from normal ISA devices by the autoconfig machinery, at all...

There's also the problem that the current I/O and memory access
interface is really "make everything look like it's a PC" for ISA,
EISA, and PCI devices, which just IS NOT POSSIBLE for some of the
weirder hardware out there.


What do i think the solutions are?

For the driver naming/bus attachment problem, i kinda like the scheme
that Matt Thomas used (and others have used; he just comes to mind).
Since, for those drivers, the bus attachment code is really all that's
_in_ the file, there shouldn't be too much trouble about renaming the
file to be bus-specific.  (i'm content with TurboChannel if_le being
"ln" as DEC named it, ISA if_le being "ile" or something closer to
what one of the vendor names for an ISA LANCE board are, etc.)

The solutions to the other problems are a bit harder.  Like, "rewrite
a fair bit of the code."

I encourage people to take a look at what i've done on the alpha.  You
won't be able to see most of it in the master source tree, though...
ftp://ftp.netbsd.org/pub/NetBSD/arch/alpha/*/src/sys.tar.gz
(And note that most of the I/O access, memory access, DMA, and device
attachment interfaces are very likely to change before I'm done with
them...  8-)


chris