Well, firstly, sorry for delaying the discussion a bit -- I'm not in the 'net all too often :-( . Furthermore, I'm forced to use ******* for the Internet because there are only ***modems around. David Brownell wrote: >It was waiting for volunteers ... we seem to have a few now! :) >Presumably you'll provide a version against the current release? > But I _did_ include an attachment (a .diff.gz file) with what I've written! You _must_ check it out because it's filled with a lot of useful comments. Anyway I include here the same one but in .tar.gz since it looks like the patch file is getting larger than the original (and besides, it's a rewrite). :-) >>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. > Yep. pci.agent calls uhci.agent and then uhci.agent calls usb.agent (giving it an extra "USB_BUS" parameter -- see below). But for this, the scripts must have a way to associate USB controller devices with USB bus numbers (and the same goes for all possible subsystems similar to USB). I haven't figured any ways so far. >>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. > _Of course_ if a specific "driver agent" can't be found then the module should get modprobe'd by the subsystem agent (I should practice English writing more :-) ). We consider _the driver agent_ as a special case. >>- 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... > Again I didn't mention everything (lack of concentration?). For the "start" and "stop" events, the usb.agent accepts a new USB_BUS parameter which is simply the name of the USB "bus" whose devices "must become available"/"needn't be available anymore" to users. Now, not passing that parameter should mean that the action applies to all USB busses. I think that should be ok. >>- 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. > Also, this way you can even have an "input.usbmap" file in the usb directory. But then, there's a new "input" agent coming up which makes this obsolete. >>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. > I didn't mention that the global ".conf" file is /etc/hotplug.conf . It's in the /etc directory and it's just like pci.conf which is in the /etc/hotplug directory and comes together with a "pci" subdirectory. Now isn't that uniform? :-) >>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. > Sounds like a good idea. I'm afraid though that I never liked having to "support" specific distributions. Hey, they're distros: _They_ had better support _us_! :-) But, anyways, for PCI and USB there doesn't seem to be anything distro-specific to do in the subsystem layer (= from the subsystem agent scripts). In the driver agents though there may be all sorts of that stuff . But I must note this _very_ important thing: We definitely want drivers packaged separately and _not_ for specific distros. But, to cover both cases: If it turns out that "drivers" are packaged distro-independently, then, for additional distro-specific files I'd recomend that they are _always_ named "*.distro-name.conf" and are sourced from the distro-indifferent "*.conf" files (and that's for both subsystem- and driver-agents). But to select one of those files, the (packaged separately) driver agent must know _simply_ the _name_ of the distro it's running on. A _standard_ environment variable should do the trick. But I don't remember if such variable is already defined. If it turns out the monolithic way then individual distros will -- yuck -- MODIFY the code however they want just so that they make it more -friendly but actually making it totally incompatible with anything else. Now that's something I've had enough of in other parts of the system. I'd rather see things to be more distro-independent, so I'll choose the first solution. In the distro-specific files, a driver or a subsystem-agent can put the (abstract) functions whose actual behavior is distro-dependent. But, once more I'll vote for distro-independence, so that these files are not necessary at all. Say, did I mention that I want things to be distro-independent? :-)