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

>It's purely a user-interface, user-convenience issue.
>
>If your first LAN interface is always at lan0, not at one of
>
>        {ae0,de0,ea0,eb0,ed0,eg0,eh0,el0,ep0,es0,fe0,hp0,ie0,ix0,iy0,lpt0,
>         ni0,ofnet0,qe0,qn0,se0,sn0,fea0,fpa0,fta0,bah0}
>
>(this list was generated mechanically, and may leave out a few things..)
>
>then scripts and instructions for doing installation and configuration
>can be much simpler.

For installation on a machine with a single interface, you may well
have a point. But once a system is instllaed, the extra configuration
and script overhead is completely negligible.  

I've tried both and I have a real objection to the naming scheme Bill
suggests.  It's not good for multihomed hosts, and it's just plain
unworkable for multi-homed hosts where the set of interfaces _or_ the
order in which they're attached changes, because the names (and thus
the mapping between a specific IP address in a config file and a
device the bus, which is done via the interface nams) don't carry
across from one change to another.

If all interfaces have the same name, that mapping can be changed by
as little as reordering cards on a bus; or by changing the order in
which the kernel probes for tehm; or (given LKM network drivers) the
order in which they're loaded.

IMHO, that's just too fragile.  In particular, it's just *not
acceptable* for NetBSD systems that are configured as firewalls.

But if you can come up with a workable scheme where *either* naming
convention works (so users with either preference can be kept happy)
then let's talk about it.