Arch (or Linux) and hardware...

Question

Hi all,
Where's a good place to learn about how linux interacts with hardware?
I want to switch to Arch from Fedora, but I know that I'll get stuck when it comes to stuff like lsmod, modprobe, udev, dev-fs and other such hardware proggies/concepts.
My knowledge in that area's virtually zilch.  So far I've stuck with Fedora coz it's the only distro that's managed to recognise my (on-board) soundcard and (on-board) network adapter.  Now, I wanna get my hands dirty :-)

Answer 1

Short summary kind of thing:
-- Modules --
modprobe <module>
finds the module and calls insmod to load the module. In general you never have to call insmod yourself but can just use modprobe. It's config file is /etc/modprobe.conf, there you can add aliasses (more on that later) and module options.
lsmod
lists all loaded modules.
modinfo <module>
gives some info about a module.
Now's the kernel support autoloading of modules, meaning that if the kernel knows what it needs it calls modprobe to load it. Sometimes it doesn't know the exact module, but only other info, an alias. Then it calls modprobe with the alias and if it can be resolved with modprobe.conf the correct module is loaded.
Autoloading happens more or less only for modules which are loaded when needed. In general that means only modules which are needed by another (already or yet to be loaded) module. Good examples are the netfilter/iptables modules which are loaded when they're needed for certain iptable rules (e.g. ip_conntrack, iptable_nat).
-- Hotplug --
Another, kind of autoloading implemented is hotplug. When the kernel detects new hardware, it spits out a hotplug event by calling /sbin/hotplug and giving it enough info so that it can find the correct module needed for that hardware.
So if you plug in a usb stick hotplug kicks in and loads the appropriate modules. The user space hotplug program (just a shellscript now, but that is changing) also calls any user scripts, filtered by type of event. That gives the opportunity to for instance mount the usb stick automatically somewhere.
This is all nice and well, but most hardware is there at startup and doesn't generate a hotplug event. So to detect all already present hardware you can execute the hotplug coldplug script to scan /sys for all hardware and load all needed modules. In arch you do this by adding hotplug to DAEMONS in rc.conf.
Of course you don't have to use hotplug, but if you want everything to "just work" then you'll probably use it. That's what most distros do. In Arch it's an option. If you know all the hardware you're going to use beforehand then you can simply add it to MODULES in rc.conf and don't have hotplug installed. You can also have hotplug installed but not run the coldplug script at startup so that if you later on plug something in it will be detected. Or you can let hotplug load almost all modules needed and leave your MODULES more or less empty.
-- /dev --
A device file is a special kind of file (like pipes/sockets/symlinks are kind of files), with the only properties that it has a major number, a minor number, and a name. It also can be a character device or a block device. A character device is anything where you read or write a stream of data, like /dev/null or /dev/mouse. A block device is anything with a given size where you can randomly read from, like /dev/hda, /dev/fb0 (framebuffer device). Everything you do on a device file is handled by the driver which handles the device with that major/minor number pair. Such driver is often compiled as a module.
The modules are automatically loaded, but one thing is missing: The device files in /dev. Simplest is to just add all possible device files to /dev. Although this sort of works, it's ugly and not a long term solution as devices get more and more random major/minor numbers. Nice that the device file is there already when you plugged in your usb stick, but which one from the hundreds is it?
The first solution to this was devfs. It's in the kernel with a userspace devfsd daemon helping it to automatically created the /dev files when needed, thus only making the files which are needed. Now /dev hadn't that awfully many files anymore, and it was simpler to find things.
Devfs had some problems though, mostly in the way it was implemented.  Although in practice it worked fine most of the time, internally it wasn't pretty and many kernel developers weren't happy with it. Though when the original maintainer sort of disappeared leaving it unmaintained and no one else stepped up, it became obsolete, as udev was there almost.
With the 2.6 kernel came /sys, a virtual filesystem which provides a lot of hardware info. This together with hotplug gives enough information to know what device file to make, if any, when a module is loaded. That's what udev does: making the needed device files with the help of hotplug and /sys.
The main reason why udev was made is to have a consistent /dev, that is, if you plug in your usb stick in port 1 it will come up like e.g. /dev/usbstick, but also if you stick it in another usb port. That is something devfs couldn't do. The next little step was to make udev so that it can replace devfs altogether and handle all device files.
As udev is totally in userspace, while devfs was unmaintained in the kernel, being a slight burden there, it was no surprise they made devfs obsolete and deemed udev it's successor. The topic udev versus devfs is politically touchy, as they're different and do things differently, not to mention that devfs was obsoleted before udev was ready for primetime (not all drivers supported /sys and hotplug yet, and udev only supports those).
Devfs brought with it also another naming scheme for /dev. Historically there were more or less no directories in /dev and all files were just dumped into /dev. Devfs made a very hierarchical structure, with files as /udev/discs/disc0/part1 instead of /dev/hda1. Some love it, some hate it. Personally I think there should be no more than one depth of subdirs, something like /dev/hda/1. With the default udev config file of Arch you get the same naming as you would get with devfs, as that was one of the main points of udev: letting the user choose the device names. With devfs + a daemon you could only choose to make symlinks.
If you know beforehand what hardware you have, and don't plug in all kind of things like usb sticks or cameras then you can use a static /dev with only the files you need. That's what I use. I also let udev handle my /udev dir, to see how well it works.
Hopefully things became more instead of less clear now. ;-)