Someone unattributed [[Bill Sommerfeld, perhaps?]] writes:

>> Perhaps one way to compromise here -- getting both user convenience
>> and driver cleanliness -- is to have a "generic" eth* or lan* wrapper
>> around ethernet devices similar to the scsibus* wrapper around SCSI
>> controllers.

The if_ethersubr.c already implements the requisite functionality for
Ethernet.  A SCSI bus is useful as an autoconfig abstraction in its
own right, because there are things (SCSI devices and slaves) that are
most naturally configured onto a ``SCSI bus''.  Off-hand I don't see
how to get SCSI disk/tape/CD unit numbers ``right'' without either a
scisbus (something common to attach them to) or some gross hacking.

I guess I'm missing the point.  What would an _autoconfig_ parent for
Ethernet, or FDDI, or whatever, devices give us that we can't already
do with config's attribute mechanism, and the kernel config attributes
that exist for ether, fddi, arcnet, etc?

Andrew Gillham writes:

>I'm just a kernel dabbler, but working on a driver for my NE3300 has
>show me one thing.  Anything that "cleans up" if_ed.c would be great!
>The NE3300 is an EISA dp8390 variant, with 32bit shared memory. I
>split the if_ed.c myself, creating /sys/dev/dp8390.c, 
>/sys/dev/isa/if_ed_isa.c, and /sys/dev/eisa/if_ed_eisa.c.

That's only part of the mess.

The if_ed driver supports three different card families that use the
same chip.  That's just broken, and it relies on a deprecated hack,
whereby the probe routines find out what kind of card is present *and*
partially initialize it; keep some extra state in the ISA-bus locators
(e.g., what kind of card is present); and pass that stateon to the
attach function.  For both portability reasons and the semantics of
how 4.4BSD config works, such hacks really should go.

Since you've split the if_ed driver youself, you've probably observed
that you still need to call the ISA probe function for the appropriate
card family, from within the attach function of your EISA device.
Otherwise, your EISA NE board doesn't get the chipset initialized
properly.  That's gross, and it's a symptom of something being wrong
in the ISA front-end.  Even if we split out a dp8390.c -- something
three people have now done -- the ISA front-end needs reworking so
that it has proper, *separate* attach and match front-end exist for
each card family, and can be called for ISA, EISA or PCI (e.g.,
RealTek 8029) devices, without calling code that frobs ISA bus
locators.  Doing that is in some respects *more* important than
splitting out 8390 code so that it works on (e.g.) Macs and Amiga
interfaces, too.  Given a separate attach front-end for each ISA card
that uses a dp8390, we *probably* want separate drivers too: the ISA
bus is going to get IOport-range size locators too, and that *will*
break a config that assumes all the 8390 chipsets are fungible.
Besides, the probes are invasive; if you want the kernel to probe for
an 3c503 *and* an SMC *and* an ne2000 at a given IO address, then you
should tell it to do so explicitly; and if you *don't*, you should
have a choice about which probes get done. IMHO anyway.



>  And, I even
>got it working correctly.. :)  Regardless, for the average joe wanting
>to mess with a device driver, the if_ed.c driver is a nightmare.
>Splitting the driver into MI/MD chunks is desperately needed, and I
>agree with Matt that card specific probes would be ideal in seperate
>chunks as well. 

I think they're really orthogonal issues; though from having tried
both, there are some issues about how ISA DMA is handled in the
receive interrupt that will affect the MI 8390 chipset driver in
less-than-desirable ways.  But I've been warned off working on this;
presumably someone else has found this, or will.

> To me this would make it easier to drop in a driver
>for some variant, without potentially breaking existing support.  


>WRT "eth*" devices, they would be useful, especially when/if NetBSD
>decides to implement subinterfaces.  

But do  we really want subinterfaces in the first place?  What do they
give us??

>A specific NIC driver shouldn't
>deal with the clutter of subinterfaces, it should just present itself
>to the upper layers as a single device.  The generic "eth0" device
>could then simply wrap (obscure?) the actual device (say "le0"), or
>allow subinterfaces.  I would love to be able to do something like:
>        ifconfig eth0 x.x.x.1 
>        ifconfig eth0.1 x.x.x.2
>        ifconfig eth0.2 x.x.x.3
>etc.. the 'alias' syntax is rather cumbersome.


There's a very noticeable lack of consensus that this is, in fact, the
`right' thing to do. It's in some ways analagous to cloning devices;
with the difference that there's no real device node for an Ethernet.
Wouldn't this break a nontrivial amount of existing code that iterates
over interfaces -- and to little gain?  You seem to be assuming it's
used for aliases; have you considered non-IP protocol stacks?

Last, I haven't looked at it, but if alias syntax is a problem, surely
we should look at fixing ifconfig's parser before we decide to change
the kernel??