12. The Linux-2.6 kernel
12.1. What is new?
Setting up your system as described above for the Linux-2.4.x kernels will be perfectly good, but with the Linux-2.6.x kernels (x = 0, 1, 2, 3 at the time of this writing) much more is possible:
USB Hotplugging of devices has been improved immensely. This means that it has become possible to attach and remove a device from the USB port with full cognisance of the system. If a device is attached, it will show in the /proc filesystem. Once it is removed, it will not show anymore.
The sysfs system has been introduced. By using this facility, a very tight grip on attached devices, their attributes and nodes of attachment is possible.
Utilities for handling hotplugging have been improved or became available. With the aid of these it is possible to easily distinguish between attached devices irrespective of the order in which they were attached.
12.2. Kernel options
Kernel configuration options are very much the same as described in Section 5.2. The configuration menu (# make menuconfig) has been organized differently and more systematically. Here are the relevant choices:
12.2.2. Device drivers
- SCSI device support
- SCSI device support (CONFIG_SCSI scsi_mod)
- legacy /proc/scsi support (CONFIG_SCSI_PROC_FS)
- SCSI disk support (CONFIG_BLK_DEV_SD sd_mod)
- USB support
- Support for USB (CONFIG_USB usbcore)
- USB device filesystem (CONFIG_USB_DEVICEFS)
- UHCI HCD support (CONFIG_USB_UHCI_HCD uhci_hcd)
- USB Mass Storage support (CONFIG_USB_STORAGE usb_storage)
12.3. Notes
It may be in your interest to consult Migrating to Linux Kernel 2.6, but it is not necessary to follow steps that cannot be followed.
12.4. Hotplugging and Naming
In Section 6.2 the situation of two USB devices plugged in at the same time was discussed. The difficulty is that it becomes hard for the user to distinguish the two devices. Progress recently made in the Linux Hotplug Project (search for hotplug) and implemented in the 2.6-series of kernels, has made it possible to address this problem efficiently. For implementation some utilities are needed:
- sysfs -- compiled by default into Linux-2.6.x
- sysfsutils-0.4.0 or later
- hotplug-2004_01_05 or later
- udev-016 or later
12.4.1. Installation
The sysfs filesystem.
The sysfs filesystem is intrinsic to the Linux-2.6 kernel series. It is used by udev and sysfstools to obtain information about kernel objects (devices, etc.), their attributes and mutual linkages. Activation is according to the following procedure:
# cd /
# mkdir sys
# mount -t sysfs none /sys
|
If you do ls -F /sys, a whole directory structure with entries like block/, bus/, ... will be shown. You were successful. The mounting should now be made permanent by adding the following line to /etc/fstab:
none /sys sysfs defaults 0 0
|
Sysfsutils.
This is installed in one of the usual ways without having to make special configuration options. Instructions in the README file are very clear. You should, however, first make sure that the entry /usr/local/lib is entered in /etc/ld.so.conf so that the libsysfs.so libraries will be recognisable by the system. After installation, check that the utilities /usr/local/bin/lsbus and /usr/local/bin/systool have been installed. Also check that the libraries mentioned above have been properly linked in (ldconfig -p | grep libsysfs).
Hotplug.
Next install the hotplug scripts. The first thing to do is to check that hotplugging will work on your system. Do: less /proc/sys/kernel/hotplug. The result should be /sbin/hotplug. If it is not so, you should add the line echo "/sbin/hotplug" > /proc/sys/kernel/hotplug to an appropriate initialization script, e.g. /etc/rc.d/rc.local. This command could also be given (as root) before checking that everything works. Installation is extremely simple. Do: # make install. Check afterwards that the script /sbin/hotplug exists.
Udev.
This is the last installation. Study the README file and follow the instructions necessary to be able to run make USE_KLIBC=true. If you have compiled the Linux-2.6.x kernel, this should not be too difficult. A quick check would be to find out if /sbin/udev and /sbin/udevinfo exist. There are other occurences as well, a very important one being /etc/udev/udev.rules. If you have a working setup for memory sticks (as described above) and a memory stick plugged in you could try ls /udev, you should see the device (sda, sda1, ...). If it is there, unplug the device and list again. It should be gone!
12.4.2. Naming memory sticks
With the udev utility in place, it is possible to identify a memory stick on the basis of some built-in attribute. One that works, is the vendor identity. To find this for an attached device, do systool -vb scsi | grep vendor. This should give a list of attached SCSI devices (remember that your memory stick poses as a SCSI device Section 6.2). Let us suppose that you have two memory sticks plugged in at the same time and found (as I did) two vendor Id's, namely "UFD" and "STORAGE". Then add to the file /etc/udev/udev.rules the following lines (at the top if you like):
## Flash Memory 1
BUS="scsi", SYSFS_vendor="UFD*", NAME="namib%n"
## Flash Memory 2
BUS="scsi", SYSFS_vendor="STORAGE*", NAME="kalahari%n"
|
The vendor-identities may have trailing blank spaces, and therefore the wildcard asterisks have a purpose. Do not ignore them. Remove and replace the memory sticks, then do ls /udev. Instead of the impersonal sda, sda1, etc. there should now be kalahari, kalahari1, namib and namib1. The devices have been named according to the "vendor" information in them. Thus we can identify the device, no matter where it was mapped. All that remains to be done is to creat appropriate mount points like /mnt/namib and kalahari and make entries like
/udev/namib1 /mnt/namib vfat,ext2 user,noauto,rw 0 0
/udev/kalahari1 /mnt/kalahari vfat,ext2 user,noauto,rw 0 0
|
in /etc/fstab to enable mounting from other places.
This is great fun ... and remember, there are other deserts on the planet.