Re: Unloading drivers, start-up, shut-down and some clean-ups

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

>   Hello everybody. I have the 2001_04_24 release of the hotplug scripts. 
> I figured it would be good to be able to automatically unload drivers 
> too so I did some work on the subject. Unfortunately, it _wasn't_ as 
> simple as implementing the "remove" event in the policy agents and so 
> that makes it a _lot_ of work on the subject. :-)

It was waiting for volunteers ... we seem to have a few now!  :)
Presumably you'll provide a version against the current release?


> My idea is to put the functonality of the ".rc" boot scripts in the 
> ".agent" scripts and have a central subsystem which triggers all others 
> (via devices of it) at startup and shutdown -- creating a hierarchy this 
> way. This means adding "start" and "stop" events and getting rid of 
> "/etc/hotplug/*.rc" scripts. 

The "rc" scripts were most handy for addressing the "coldplug" case,
supporting subsystem-specific startup/shutdown.  I'm sure you noticed
there was a bunch of USB-specific stuff crying out for better homes.


>    An example is that a PCI device (the host 
> controller) is what "enables" the USB subsystem (or a part of it in the 
> case of multiple controlers). So it goes for all other cases as long as 
> the hotplug scripts are dealing only with hardware devices. This way the 
> subsystems will be "started" and "stopped" in an order which is more 
> appropriate than the current lexical order.

Right.  I forget why I never implemented that; likely it was just a lack
of time to refactor things.  There should certainly be scripts that make the
USB subsystem start up when PCI hotplugs a USB controller.


> My suggestion is also to have driver-specific "*.agent" (instead of just 
> "*" scripts:-)) scripts which will be called _in place_ of  (and not in 
> addition to) modprobe (of course, they will call modprobe themselves if 
> necessary).
> - This makes it possible for scripts to do their stuff before and/or 
> after "modprobe"ing.
> - It also eliminates the need for a blacklist (you (or a package) can 
> simply add empty agents)

If there's no such agent, there needs to be a default behavior.
Most driver developers should never need to write those scripts,
they certainly would view such a requirement as a bug.

And the default behavior for network drivers needs to be a bit
sensitive to what distro it's running on.  It'd be nasty to need to
have N distro's worth of scripts for M drivers = NxM...

But otherwise a "*.agent" that's more flexible seems like a
fine update.


> - It completes the previous hierarchical design which I was talking 
> about. "uhci.agent" for example can "start" the USB subsystem when "added" .

Except that there still needs to be some common place for generic
USB setup, shared by all the host controllers (uhci, ohci, ehci, and
sometimes non-pci ones).  And as a USB developer I do want to
be able to start and stop the USB subsystem by itself...


> - The driver-specific *.agent files can be enumerated very simply (with 
> this glob).
> - The driver-specific policy agents can have their own homes and invite 
> friends and relatives as well... :-) I mean that each driver-specific 
> agent can have its own driver-specific subdirectory (just like each 
> subsystem-specific agent can have its own subsystem-specific subdirectory).

Also good.


> - Aside the previous, each driver (and this is the most useful part) can 
> have its own .usbmap (or .pcimap or similar) in the subsystem-specific 
> directory. This *.usbmap (as an example) file should be parsed as well 
> by usbmodules. This makes usb.handmap, usb.usermap and similar files 
> unnecessary.

I'd say it mostly moves them around, rather than making them become
unnecessary.  Generalizing is good.


> Another thing is that the individual policy agents should be separated 
> from each other (/etc/hotplug/hotplug.functions is ugly :-)) and thus 
> should have very few common parts. That's because future hotplug agents 
> might not be only (or at all) for (un)loading kernel modules for 
> hardware devices and they just can't ignore any common functions (like 
> driver-loading functions or so) that are given to them. Now, that may 
> sound bad since it means duplicating a couple of lines of script but I'm 
> playing safe :-)...

That's something I'll disagree with -- duplicating lines of code is
something I've usually found to be more dangerous than having
one master copy.  Bugs and features need to stay in sync.


> Here's a file layout:
> - Anything matching /etc/hotplug* is hotplug specific
> - Anything matching /etc/hotplug/xxx* is xxx-subsystem-specific.
> - Anything matching /etc/hotplug/xxx/yyy* is yyy-driver-specific.

As it is today -- except /etc/hotplug/ is always a directory, there
are no other /etc/hotplug* files.


> Here's a uniform naming scheme:
> - If * corresponds to nothing then it's a directory.
> - If * corresponds to ".agent" then it's a script that processes hotplug 
> requests.
> - If * corresponds to ".conf" then it's sourced from the corresponding 
> .agent script and related ones.

Sounds reasonable.  Would the "*conf" files be where
distro-specific magic happens?  That's a big issue; it'd
be good to have nice clean places to hang customization
for Debian/RedHat/SuSE/etc and their config policies.

- 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