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?

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

I'm writing mainly to get any comments from everyone. I realize the
description above's sketchy. My main question is about drivers from
other OS's. What do maintainers thereof think? Is there something
I can do to make life easier? I don't think I can do all the
gyrations needed for the various drivers, but I can help.

I'm still in the middle of generating diffs, so I haven't hit all
the snags. But the driver which looks like it was the easiest to do
was dev/ic/am7990.c. It had a line up at the top:
#define ifp	(&sc->sc_ethercom.ec_if)
which, when changed to
#define ifp	(sc->sc_ethercom.ec_if)
was one of only three changes. The other two were to actually
allocate the ifnet, and then to incriment the refcount when the
interface's address was copied into the received packet's mbuf.

Would defining a variable, say IFALLOC, help?

Take care,

Bill