> 
> At 07:46 PM 7/9/97 +0200, Matthias Drochner wrote:
> >[postpone softc revoval]
> >
> >Jason wrote:
> >> Anyhow, I don't like that idea so much... It seems much less correct to
> >> me... But, I don't have the time or energy to get into an argument about
> >> it, so...

You're probably right that it's less correct, but there's just so much
code out there that assumes that an ifnet's in an ethercom or arpcom.
The drivers we share with other Un*xes are the ones I'm thinking about.
I just can't see an easy way, other than the #define ifp
(sc->sc_ethercom.ec_if)  trick, to easly handle the difference. And that
trick strikes me as obscuring what's going on.

> >Perhaps I can help here :-)
> >The softc removal should happen in a higher level
> >of the driver LKM load/unload code because
> >this is needed for all devices, whether it is a network
> >interface or not.
> 
> But the driver should be able to veto/delay of freeing of the
> softc because there may be outstanding references to it
> that the driver load/unload doesn't know about.  When asked
> to unload, the driver will say no.  When ready, the driver
> will inidicate that it can be deleted.  the unload code (from a
> clean stack) will then free the softc and unload the driver.

As I see it, we have two uses for if_detach. Either the hardware (pcmcia)
or the driver (lkm) is going away. If it's the hardware, the pcmcia
code tells the driver, "you're card's gone". The driver (probably at
interrupt time) turns off interrupt handlers (or sets them to null or
whatever), and calls if_detach. Then the interrupt routine returns.
When the reference count goes to zero, possably within if_detach,
the callback gets rid of the softc.

If it's the driver, we need to wait for the ifnet/softc to be free
before removing the driver (if only that the softc free'er is in the
driver :-)

So when we unload an lkm interface, we do as above. But before the
call to if_detach, we set some internal flag in the softc. Then we
if_delete. If the refcount's not zero, we change the above internal
flag, and sleep on the address of the interface. Since lkm removal
happens at spl0, (doesn't it :-)  this is no big deal. When the refcount
is 0, we delete the softc. When the lkm's if_iffree routine gets
called, if the internal flag's set indicating that we're sleeping, it
wakes up the sleeper. If the flag indicates that we're in if_detach,
then if_iffree does nothing as the softc will get deleted when we
return from if_detach.

So basically the lkm driver does make the lkm removal wait for the
references to drain.

lkm pcmcia ifnets would only be complicated by the need to handle the
sick case of someone popping out the card and then unloading the
lkm before the ifnet gets freed (basically something goes from case 1
to case 2 while its waiting for the protocol stacks to process packets).

Would this sound livable?

Take care,

Bill