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

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

best regards
Matthias