At 01:41 PM 7/8/97 -0700, Bill Studenmund wrote:
>Hello,
>
>After asking about if_delete a while back, I got a lot of suggestions,
>including a few good ones from Jason. The end result of all this is to
>do if_delete right would mean a minor but large change to the kernel.
>
>Huh?

Ouch.

>The idea is to make struct ifnet's more like vnodes in that they
>come from an if_alloc and go away with an if_free. Relevant parts
>of code will if_addref and if_delref the ifnet.
>
>The main change is that a lot of network interfaces have an
>ethercom or arccom in them, and reference ifnet variables as
>sc->sc_ec.ec_if.if_xname. That'll need to change to
>sc->sc_ec.ec_if->if_xname. There are other changes to sys/net
>stuff, but the only driver-ish ones are the indirection above,
>allocation of an ifnet (if_alloc()) in the config or attach
>routines, and the setting up of a new field, if_ifcom, which
>holds the address of an associated ethercom or arccom, for parts
>of the kernel that used to think that &(struct ethercom) ==
>&(struct ifnet).

Ouch.  That will make significantly more painful for me.  I'd
rather have int (*if_freeself)(struct ifnet *) member added.  If
NULL, the ifnet can not be deallocated.  It returns 0 on successful
deletion or an error on failure.

I can see if_delete for slip/ppp/tun/* but not real ethernet hardware
which will be known at boot time.  (unless we want to LKM's.)
-- 
Matt Thomas               Internet:   matt@3am-software.com
3am Software Foundry      WWW URL:    http://www.3am-software.com/bio/matt.html
Nashua, NH                Disclaimer: I disavow all knowledge of this message