Re: Unloading drivers, start-up, shut-down and a rewrite (a problem)

[David Brownell <david-b@pacbell.net>]

Hi Keith,

> I am not convinced that we need a separate count, at least not at the
> bottom layer.  The module use count is a pure reference count on the
> module code, rmmod does not care what the types of reference are, rmmod
> just cares if it is safe to unload the code.

While "rmmod" may not care, there are two distinct user communities
that IMO need to be supported:

- "real users", 95+% of the computer users in the world, who want
  things to "just work" and never need root access or a sysadmin;

- "sysadmin" or "developer" ... who does troubleshooting/upgrading/...
  and so needs extra system capabilities.

I think "one use count" might work for a "real user", but not for anyone
who wants safe ways to replace drivers on running systems.  If there's
just one use count, adjusted in userland, it'd be too easy for userland
bugs to corrupt things.  (What do you mean by "need"? :)


> >Likely "rmmod" needs a flag that says whether the device count is
> >ignored, as (effectively) done today. Driver developers will want the
> >flexibility to say "remove this driver even though there's hardware
> >attached, I've got a bugfix".  USB developers work in that mode
> >today, it's quite handy.
> 
> See above, I don't see any need to distinguish between references.

How would someone SSH into a system and upgrade some of its
drivers?  With two counts, one can shutdown all code using the
drivers (use count goes to zero), then say "ignore any hardware,
just remove the driver".  And then start things up again; perfectly
safe, even a sleep-deprived and seriously aggravated sysadmin
can't make mistakes (run some command too many times :) and
thereby crash the server (consequences left to your imagination).


>  If the device is up then the module cannot be unloaded.  That does assume
> that all devices can be deactivated which is not currently true, to do
> this properly every device driver would need an up and a down routine.

If "up" is a software notion, that's what I see the current use count as
being used for.  (I can't see it being a hardware notion...)  But I'm not
sure what you're saying "is not currently true".

Hotpluggable drivers get told when the hardware comes and goes,
by USB or PCI etc.  With USB, that doesn't modify any use counter,
ensuring that drivers can safely be reloaded so long as they're not
actually in use.  If the hardware is accessed through the file system
device nodes, open/release routines apply; network drivers have up/down
analogues.  Those all (should) update the current use count, keeping
the driver from being unloaded until the device becomes inactive.


> I can add a use count up/down interface to kernel/module.c without
> waiting for every driver to be converted to an up/down interface.

The same with MOD_{INC,DEC}_DEV_COUNT() support;
it's not drivers that'd need converting, but subsystems.  Two lines
(each) in the right places of usb.c, pci.c (or wherever).
Changing every single driver would be wrong, I'd agree.


> However we have to agree on a common design for drivers, I would hate
> to see some modules supporting up/down and others doing it a different
> way.

We have USB pretty well in hand, as I described above.  It could again
serve as a guinea pig ... :)

- Dave



_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel