udev, hotplug, hal, dbus : implementation
 

Hi, all -

Could someone point me to a thorough explanation of what, exactly, happens when, for example, I plug (1) a USB network adapter into a 2.6.x machine running Debian etch or Fedora Core 3 & up, (2) a USB memory card / "jump drive" into same, (3) the base station for a Palm && initiate a hotsync?

I'm asking this because I've managed to get all of those devices working at one point or another. However, at least one something has changed on at least one occasion. For example, to deal with my Lexar Jump Drive, I used to use the following rule:
I could then add the following to fstab:
And, assuming I had issued the following commands:
when I inserted the device, a couple of things would happen:
* /dev/jdd0 (or 1, ...) would be created
* /dev/jdd0 would be mounted to /mnt/jumpdrive

Alternatively, I could include RUN in the udev rule && launch nautilus && display the files on the drive, etc.

I noticed, however, the other day, that the drive was being mounted, and a nautilus window displaying all the files on the drive was showing up, even though I had not yet added that rule.

To make matters worse, when I went looking on a Debian system, it seemed that there were some distinct differences between how whatever-it-is that was getting done on that system and on a Fedora Core 6 system.

At this point, what I'm hoping to find is something that explains the entire process conceptually, so I can then follow it on a specific implementation. Also, I know hotplug has changed over the course of the last few years; if someone knows of a synopsis of those changes, I would be greatly appreciative.

I know I'm not the only one who's tried to get their brain around this; the worst thing about it is that I did understand it well enough to make it work appx two years ago, but apparently, enough has changed in that time that I'm a bit lost.

Thanks in advance,
Larry

That's HAL.
A couple of articles you might find interesting:
Making Hardware Just Work
Hal Specification
"hotplug" was used by the 2.4 kernel series.

It isn't used by the 2.6 kernel at all.
With newer distros, everything is meant to work right out of the box without any user intervention at all.

Ah. Thanks; that makes serveral things make a lot more sense. Thanks for the article links too...

Let me see if I've got this right: the kernel signals udev via dbus when a device is added to the system, and udev uses "agents" - which might be named '.agent' or might not, depending upon what type of device we're dealing with - to load modules, etc.? And, at any point in the process, HAL might decide, based on the policies that have been defined for a given device on a given system, to do (or not do) something as well, right?

In the case of a jump drive, the kernel tells udev, via dbus, that the thing is there; the appropriate agent for the type of device it is, is run, and loads the right driver for the device if it needs to be loaded. The first agent called loads ehci_hcd; one called after that one loads "usb"; one called after that one loads "usb-core"; and, finally, one of them loads sd_mod. And does whatever else the policy for the device specifies it ought to (eg., mounts the drive)? And, at any point in the chain, HAL is potentially able to change various aspects of the system's behavior based on the policy(ies) that is(are) applicable to that piece of hardware.

Does that sound about right to you? Also, wouldn't that mean the newer the 2.6.x kernel you had, the more able it was to recognize devices and generate the appropriate initial message(s) to udev, resulting in a much smaller set of .rules files in /etc/udev? And potentially a less complicated udevd?

There are certainly a lot of variations on this theme with respect to how this all happens; Debian has its way, RedHat has its way, SUSE is using an altogether different methodology... Even between versons of the same distro there isn't all that much consistency, which is part of what lead me to what I hypothesized regarding the kernel (above).

Thanks, everyone, for your time.