> Yes, this would be ok from the driver LKM point of view.
> If I understand it correctly, it would boil down to a
> function which is called by the driver at unload time
> (let's call it detach function) and which tells if a given
> ifnet can be freed. The (userland) unload program has
> to retry in necessary.

If a userland program is trying to detach a driver, can't we just
sleep until it's done?

> But Bill's idea was to detach automatically when the
> refcount drops to zero. If this is done, it should be done
> for all loadable stuff. And this would require lots of
> changes... I've played with loadable drivers for quite a
> while, and trapped into various interdependency problems.
> Partly unloaded LKM's must be avoided - either a complete
> LKM is removed or nothing.

My idea's been a moving target. :-)

One thing to point out. The only way the refcount could get to zero
(barring unbalanced if_delref()'s) is for something to explicity
call if_detach. One of the outstanding references to an ifnet is the
softc or ethercom in which its pointer (or it, if we leave ifnets there)
is stored. if_detach does an if_delref to release it. If you never
call if_detach, the ifnet will never get free'd.

> (Eg, we have a LKM consisting of a driver and the
> corresponding cdevsw. The open()/close() functions
> maintain a refcount for the device. If we naively start
> unloading while the device is oped by a user task, the
> cdevsw will be unloaded. The close() function renders
> unaccessible and the device can never be freed.
> I fear similar lockups can happen with a combined
> network interface / protocol domain LKM too.)

I don't understand the above idea. Why do we unload on an open()?

I agree that we need to be careful, but since these ifnets (or softc's
containing them) won't be freed without something initiating the
freeing, we should be able to control what happens and check for
dependancies.

Take care,

Bill