Mercurial > hg > kdocs
changeset 53:87598e3a8e3c
Quick note about devfs (obsolete) and first half of hotplug-history.html.
author | Rob Landley <rob@landley.net> |
---|---|
date | Fri, 28 Sep 2007 17:57:21 -0500 |
parents | ecfa70db0bb3 |
children | 3ee4d4f91685 |
files | local/hotplug-history.html master.idx |
diffstat | 2 files changed, 271 insertions(+), 0 deletions(-) [+] |
line wrap: on
line diff
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/local/hotplug-history.html Fri Sep 28 17:57:21 2007 -0500 @@ -0,0 +1,259 @@ +<html> +<title>The history of hotplug</title> +<body> + +<h1><b>The history of hotplug.</b></h1> + +<h2>What is hotplug, what problems does it solve, why do we have the current +set of hotplug mechanisms, and what legacy mechanisms did the current +hotplug implementation obsolete?</h2> + +<ul> +<li><a href="#before">Before hotplug</a></li> +<li><a href="#removable">Removable media</a></li> +<li><a href="#modules">Modules</a></li> + +<h2><a name="before"><b>Before hotplug: static everything.</b></h2> + +<p>Originally, the kernel had no hotplug capability. A kernel without hotplug +manages a fixed set of hardware, all of which is detected and initialized at +boot time, and all of which remains present until the system is shut down. +This is very simple, but also very limited.</p> + +<p>This meant device drivers statically linked into the kernel image, +and a /dev directory filled of device nodes for every potential device +when the system was installed. A program that wanted to probe for available +hardware sifted through /dev and opened devices it found there, elminating +the ones which gave an -ENODEV error.</p> + +<p>One reason for this was simplicity, but equally important was that early PCs +were not designed around hotpluggable hardware, and Linux started out on a PC. +When the PC was introduced, users couldn't even switch keyboards while the +machine was on without risking hardware damage.</p> + +<p>[FOOTNOTE]Of course users widely ignored this constraint whenever they could. Users +hotplugged keyboards, serial, and parallel devices all the time, no matter +what the manufacturer said, and by the late 80's most hardware developers had +adapted to reality and buffered their more vulnerable external I/O ports. But +the number of keyboard, serial, and parallel ports on the machine remained +fixed, and each port could handle only one device at a time, so drivers focused +on handling ports and left figuring out what device was behind an I/O port to +the userspace application trying to talk to that device.[/FOOTNOTE]</p> + +<h2><a name="removable">Removable media</h2> + +<p>The original PC did have one type of early hotplug: it had removable storage +media in the form of floppy drives (and later, CD-ROM drives, zip disks, +and DVD drives). The first stirrings of hotplug support came from Linux's +need to cope with removable media.</p> + +<p>With removable media, the contents of the corresponding block devices +changed, including even the size of the media represented by those block +devices. Since filesystems could depend on those block devices, and processes +depended on those filesystems, in extreme cases ejecting a floppy could +lead to a kernel panic.</p> + +<p>The kernel's response to this was to ignore as much of the problem as +possible, and work around the rest. Removable media was treated as a special +case, and the kernel grew workarounds rather than any real systematic +solution to a larger generic problem.</p> + +<p>Since the drives themselves stayed around awaiting the insertion of +new media, media were treated as a property of drives, and most drives could +have exactly one instance of removable media in them at a time anyway. +[FOOTNOTE]There were "jukebox" style multi-CD changers, but they were poorly +supported and mostly treated like a single drive with multiple +partitions.[/FOOTNOTE] +So device drivers used device nodes representing the drive instead +of the media, and when the drive contained no media the driver would respond to +attempts to access the drive's device node with error codes.</p> + +<p>Poor hardware support for hotplug continued to be a problem: most removable +media provided no notification mechanism to inform the system +when media was inserted or removed. The driver could probe the device to +see what media it contained at any given moment, but no interrupt was +generated to signal changes. Thus the kernel +had no way to respond to the a block device's removal except via extensive +error handling after the fact.</p> + +<p>Applications using removable media probed for them or +received error codes on attempted access to an empty drive, and the kernel +developer's advice about dealing with the problems of removing a mounted +volume was "don't do that": inserting or removing media when the system didn't +expect it was dismissed as user error.</p> + +<h3>A workaround: drive locking</h2> + +<p>To avoid being surprised by the unexpected removal of media containing +a mounted filesystem, some drives grew the ability for software to "lock" +a drive, preventing it from ejecting its media until it was unlocked. +(Pressing the eject button still didn't generate an interrupt, it simply had +no effect until the software unlocked the drive.) This let the operating +system force users to eject removable media from software (via the "eject" +command) rather than by pressing the button on the drive, allowing the OS to +safely use the block device at the expense of annoying users.</p> + +<p>By locking the drive to prevent unauthorized eject, the hotplug-less kernel +avoided having to unmount filesystems on short notice. This meant the kernel +didn't have to promptly flush buffers when data was written to the device (to +minimize unmount time), and that the kernel could veto attempts to unmount a +filesystem that was still in use for any reason, such as due to any process +having open files in that filesystem or that filesystem containing any +process's current directory. (Yes, even though a process's current directory +could be deleted, it couldn't be unmounted. Not for any deep technical reason; +support for it simply hadn't been implemented. Removable media was a poorly +supported afterthought.)</p> + +<p>Of course some drives (most notably PC floppy drives) had no provision for +locking the drive; ejecting a floppy was a manual process controlled by a +purely mechanical button. Users that didn't remember to manually unmount a +floppy lost data, and were largely mocked as clueless by traditional Unix +developers (or else PC hardware was mocked for not having drive locking +support). The "mtools" package provided a popular workaround, reading and +writing FAT files directly through a floppy disk's unmounted block device, +probing for media before each command, and flushing all data after each +command. (It even accepted dos-style names for floppy drives.)</p> + +<p>As late as Linux 1.0, support for eject was still a special case for CDROM +drives (/include/linux/cdrom.h had a "#define CROMEJECT"), and door locking +support was a special case for SCSI (/drivers/scsi/sci_ioctl.h #defined +SCSI_IOCTL_DOORLOCK). As late as Linux 2.4, the underlying problems +with dynamically unplugging block devices were considered too hard to +properly solve.</p> + +<h2><a name="modules">Modules</h2> + +<p>The first serious hotplug mechanism in Linux was modules, because modules +allow device drivers to be loaded after the kernel boots and unloaded again +before shutdown.</p> + +<p>Hotplug was a side effect, since most hardware used by Linux still wasn't +hotpluggable. The primary motivation for modules was reducing the memory +footprint of kernels, which was increasing due to the proliferation of device +drivers. A generically configured kernel, such as those in the emerging Linux +distributions, needed to be built with drivers for every piece of hardware it +might encounter, but most systems it ran on would use only a small subset of +those drivers.</p> + +<p>Modules meant that device drivers could probe for hardware present when the +module was inserted, after the kernel booted. A module that failed to find any +devices (of the kind it contained a device driver for) could refuse to load, so +attempting to load all modules was a simple way of probing for available +hardware. Modules could even be removed and re-inserted to scan for and handle +new hardware.</p> + +<p>This was an improvement, but not a complete solution. Using modules as the +primary hotplug mechanism quickly revealed numerous deficiencies: the +granularity was wrong, there were insufficient notification mechanisms, and +this approach didn't handle configuration issues like device nodes.</p> + +<p>The granularity is wrong because a module encapsulates a device driver, and +one instance of a driver can manage multiple instances of a device. When +inserting a second instance of a device into a system, removing the module to +reinsert it (and thus find the new instance of the device) takes the first +instance of the device offline. This is an extremely unpleasant side effect, +and not always possible if the device is in use.</p> + +<pre> +More to come... + +Ad-hoc mechanisms to rescan busses + + +module manages muliple devices; insert a second ethernet card. + Need a way to tell module to rescan devices. + Still need a separate notification mechanism to trigger module loading. + Module loading either has to happen _after_ device insertion, or module + has to be told to rescan after module loaded. + Doesn't handle unplug. + Notification problem worse: ideally need to know before device goes away + so flush buffers, umount filesystems, close file handles, etc. Cleanup. + Unloading module. + Doesn't handle /dev entries. + Fill up /dev with every possible device, there could be thousands of them. + (Every possible partition on every possible hard drive...) + How does userspace know which ones are active? (In a static /dev, presence + of an entry gives no information about whether or not the device is there. + Iterate through the lot and test. Very slow, timeouts, generates spurious + activity that can have unwanted side effects like spinning up drives...) + + +<h2>PCMCIA</h2> The arrival of PCMCIA (a hotpluggable 16-bit expansion card bus for early laptops) provided the first , USB, laptop docking stations, + +static everything. +modules +The /proc directory + Rescan scsi bus via /proc/scsi + http://bash.cyberciti.biz/diskadmin/rescan-scsi-bus.sh.php +laptops (pcmcia) +USB + Added in 2.2.7, written by Linus Torvalds throwing out earlier work. +devfs + Having the driver detect the presence of hardware is backwards. Driver + loads in response to device being plugged in, but the driver detects the + existence of the device... chicken and egg problem. + +The biggest problem with devfs +is that device nodes and physical devices aren't the same thing. Some device +nodes have no corresponding hardware (such as /dev/null), and some devices +have multiple device nodes (such as partitioned hard drives). Devfs had no +way to tell userspace what actual devices the system had separate from what +drivers were loaded, which was especially problematic when a newly inserted +device required some action from userspace (loading modules or firmware) before +device nodes could be created for it. And some USB devices can be driven +entirely from userspace, with no kernel device driver + + A device that requires some action to +be taken (such as a userspace program loading firmware into it) between +device insertion and device node creation, Suppose device that requires firmware to +be loaded (by userspace) before a device driver can probe it and create +appropriate /dev nodes +of information was missing from userspace.</p> + + + +sysfs + Finally, the modern approach. + /sbin/hotplug vs netlink + + Also, devfs provides /dev entries, but that's the wrong layer. Some + hardware provides multiple /dev entries (partitioned hard drives), some + dev entries have no underlying hardware (/dev/zero, /dev/null, network + block devices), and some devices have no /dev entry (ethernet, for + historical reasons). + + + + + + +<h2>Static drivers, modules, and hotplug.</h2> + +A kernel without any hotplug capability manages a fixed set of hardware, +all of which is detected and initialized at boot time, and all of which remains +present until the system is shut down. + +The Linux module loading mechanism allowed drivers to be loaded after the +system boots + + + +Early atte + +Hotplug allows the kernel to dynamically respond to the addition or removal of +hardware. At boot time, + +/sbin/hotplug or netlink. +Support for hotplug in Linux evolved out of Linus's rewrite of USB +</body> +</html> + +note: + What's the probe for removable media? (ioctl()?) + +http://kerneltrap.org/node/1893 +http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs +http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ +http://kerneltrap.org/node/5340 +http://kerneltrap.org/node/6744 +</pre>
--- a/master.idx Fri Sep 28 14:47:26 2007 -0500 +++ b/master.idx Fri Sep 28 17:57:21 2007 -0500 @@ -188,6 +188,18 @@ </span> <span id="rootfs"> </span> + <span id="devfs (obsolete)"> +<p>Devfs was the first attempt to do a dynamic /dev directory which could change +in response to hotpluggable hardware, by doing the seemingly obvious thing of +creating a kernel filesystem to mount on /dev which would adjust itself as +the kernel detected changes in the available hardware.</p> + +<p>Devfs was an interesting learning experience, but turned out to be the wrong +approach, and was replaced by sysfs and udev. Devfs was removed in kernel +version 2.6.18. See +<a href=local/hotplug-history.html>the history of hotplug</a> for details.</p> + + </span> </span> <span id="Network"> <span id="nfs">