Linux - HardwareThis forum is for Hardware issues.
Having trouble installing a piece of hardware? Want to know if that peripheral is compatible with Linux?
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Location: East Coast, USA (in "the great northeast")
Distribution: Custom / from source; Fedora, Debian, CentOS, Scientific; LFS.
Posts: 94
Rep:
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:
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.
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.
That's HAL.
Quote:
Originally Posted by HowDoIProgramIt
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.
Location: East Coast, USA (in "the great northeast")
Distribution: Custom / from source; Fedora, Debian, CentOS, Scientific; LFS.
Posts: 94
Original Poster
Rep:
Quote:
Originally Posted by rkelsen
"hotplug" was used by the 2.4 kernel series.
It isn't used by the 2.6 kernel 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).
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.