Then press the / key (which initiates a search) and type in the configuration option, minus the CONFIG_ portion of the string.This process is shown in Figure 7-1.

The kernel configuration system will then tell you exactly where to select the option to enable this module. See Figure 7-2.

The first item in the display exactly matches what you searched for.The location information in the display tells you that to build the module E1000 into the kernel, and the following configuration option must be enabled:

Example: A USB device

As another example, let’s look at a USB-to-serial converter that is present in our example system.It is currently connected to the /dev/ttyUSB0 port, so you need to look in the sysfs tty section:

You can trace through sysfs for this device to find the controlling module, as shown in the previous section:

Then search the kernel source tree to find the configuration option that you need to enable:

Use the kernel configuration tool, as shown in Figure 7-3, to find the proper

In our case, this displays the screen shown in Figure 7-4.

This shows exactly where to find the USBProlific2303SinglePortSerialDriver option that is needed to control this device properly.

Summary of device discovery

In summary, here are the steps needed to find the driver for a device that has a working driver already bound to it:

Let the kernel tell us what we need

Now that we have gone through all of the steps of poking around in sysfs and following symlinks to module names, here is a very simple script that will do all of that work, in a different way:

You can download an example file containing this script from the book’s web site, provided in the “How to Contact Us” section of the Preface.

This script goes through sysfs and finds all files called modalias .The modalias file contains the module alias that tells the modprobe command which module should be loaded to control this device.The module alias is made up of a combination of device manufacturer, ID, class type, and other unique identifiers for that specific type of device.All kernel driver modules have an internal list of devices that they support that is generated automatically by the list of devices the driver tells the kernel it supports.The modprobe looks through this list of devices by all drivers and tries to match it up with the alias it has.If it finds a match, it will then load the module (this procedure is how the automatic driver loading functionality in Linux works).

The script has the modprobe program stop before actually loading the module, and just print out what actions it would take.This gives us a list of all of the modules that are needed to control all devices in the system.A little cleaning up of the list, by sorting it and finding the proper field to display, results in this output:

This is a list of all of the modules that are needed to control the hardware in the machine.

The script will also probably print out some error messages that look like:

Which means that it could not find a module that can control that device.Do not be concerned about this, as some devices do not have kernel drivers that will work for them.

This is the device we wish to get working.*

* Note that you can just try searching through the kernel configuration for a device that matches the string described here, a device from Realtek Semiconductor with a product name of RTL-8139/8139C/8139C+, but this does not always work.That is why we are taking the long way around in this chapter.

Almost all distributions place the lspci program in the /usr/sbin/ directory, but some place it in other locations.To find out where it is located, enter:

$ which lspci
/usr/sbin/lspci

$ cd /sys/bus/pci/devices/
$ ls
0000:00:00.0 0000:00:1d.0 0000:00:1e.0 0000:00:1f.3 0000:06:03.3
0000:00:02.0 0000:00:1d.1 0000:00:1f.0 0000:06:03.0 0000:06:03.4
0000:00:02.1 0000:00:1d.2 0000:00:1f.1 0000:06:03.1 0000:06:04.0
0000:00:1b.0 0000:00:1d.7 0000:00:1f.2 0000:06:03.2 0000:06:05.0

$ cd 0000:06:04.0

$ cat vendor
0x10ec
$ cat device
0x8139

$ cd ~/linux/linux-2.6.17.8/

$ grep -i 0x10ec include/linux/pci_ids.h
#define PCI_VENDOR_ID_REALTEK 0x10ec

$ grep -i 0x8139 include/linux/pci_ids.h
#define PCI_DEVICE_ID_REALTEK_8139 0x8139

$ grep -Rl PCI_VENDOR_ID_REALTEK *
include/linux/pci_ids.h
drivers/net/r8169.c
drivers/net/8139too.c
drivers/net/8139cp.c

static struct pci_device_id rtl8169_pci_tbl[] = {

{ PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8169), },

{ PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8129), },

if (pdev->vendor == PCI_VENDOR_ID_REALTEK && pdev->device == PCI_DEVICE_ID_REALTEK_8139 && pci_rev >= 0x20) { dev_info(&pdev->dev,

"This (id %04x:%04x rev %02x) is an enhanced 8139C+ chip\n", pdev->vendor, pdev->device, pci_rev); dev_info(&pdev->dev,

"Use the \"8139cp\" driver for improved performance and stability.\n"); }

The use of the PCI_VENDOR_ID_REALTEK value here also corresponds with the code that checks whether the PCI device ID matches the PCI_DEVICE_ID_REALTEK_8139 value.If it does, the driver is to print out a message that says: “Use the 8139cp driver for improved performance and stability.” Perhaps we should look at that driver next.Even if we did not have such a visible clue, the 8139too.c driver does not have the vendor and device ID pair that we are looking for in a struct pci_ device_id variable, so that gives us the clue that it will not support our device.

Finally, look at the drivers/net/8139cp.c file.It uses the PCI_VENDOR_ID_REALTEK definition in the following code segment:

Here is a use of both our vendor and device ID values in a structpci_device_id variable. This driver should support our device.

Now that we have the driver name, we can work backward, as shown in the first section in this chapter, to find the proper kernel configuration value that should be enabled to build this driver.

In summary, here are the steps needed in order to find which PCI driver can control a specific PCI device:

$ /usr/sbin/lsusb
Bus 002 Device 003: ID 045e:0023 Microsoft Corp. Trackball Optical
Bus 002 Device 001: ID 0000:0000
Bus 005 Device 003: ID 0409:0058 NEC Corp. HighSpeed Hub
Bus 005 Device 001: ID 0000:0000
Bus 004 Device 003: ID 157e:300d
Bus 004 Device 002: ID 045e:001c Microsoft Corp.
Bus 004 Device 001: ID 0000:0000
Bus 003 Device 001: ID 0000:0000
Bus 001 Device 001: ID 0000:0000

$ /usr/sbin/lsusb | grep -v 0000:0000
Bus 002 Device 003: ID 045e:0023 Microsoft Corp. Trackball Optical
Bus 005 Device 003: ID 0409:0058 NEC Corp. HighSpeed Hub
Bus 004 Device 003: ID 157e:300d
Bus 004 Device 002: ID 045e:001c Microsoft Corp.

$ /usr/sbin/lsusb | grep -v 0000:0000
Bus 002 Device 003: ID 045e:0023 Microsoft Corp. Trackball Optical
Bus 005 Device 003: ID 0409:0058 NEC Corp. HighSpeed Hub
Bus 004 Device 002: ID 045e:001c Microsoft Corp.

Bus 004 Device 003: ID 157e:300d

$ /usr/sbin/lsusb | grep 157e
Bus 004 Device 004: ID 157e:300d

$ grep -i -R -l 157e drivers/*
drivers/atm/pca200e.data
drivers/atm/pca200e_ecd.data
drivers/atm/sba200e_ecd.data
drivers/net/wireless/zd1211rw/zd_usb.c
drivers/scsi/ql1040_fw.h
drivers/scsi/ql1280_fw.h
drivers/scsi/qlogicpti_asm.c

static struct usb_device_id usb_ids[] = { /* ZD1211 */ { USB_DEVICE(0x0ace, 0x1211), .driver_info = DEVICE_ZD1211 }, { USB_DEVICE(0x07b8, 0x6001), .driver_info = DEVICE_ZD1211 }, { USB_DEVICE(0x126f, 0xa006), .driver_info = DEVICE_ZD1211 }, { USB_DEVICE(0x6891, 0xa727), .driver_info = DEVICE_ZD1211 }, { USB_DEVICE(0x0df6, 0x9071), .driver_info = DEVICE_ZD1211 }, { USB_DEVICE(0x157e, 0x300b), .driver_info = DEVICE_ZD1211 }, /* ZD1211B */ { USB_DEVICE(0x0ace, 0x1215), .driver_info = DEVICE_ZD1211B }, { USB_DEVICE(0x157e, 0x300d), .driver_info = DEVICE_ZD1211B }, {}

};

{ USB_DEVICE(0x157e, 0x300b), .driver_info = DEVICE_ZD1211 },

1. Find the USB vendor and product ID of device for which you want to find the driver, using lsusb after adding and then removing the device to see what changes in the list.
2. Search the kernel source tree for the vendor and product ID of the USB device.Both the vendor and product ID should be in a structusb_device_id definition.
3. Search the kernel Makefiles for the CONFIG_ rule that builds this driver by using find and grep :

Root Filesystem

The root filesystem is the filesystem from which the main portion of the running system boots.It contains all of the initial programs that start up the distro, and also usually contains the entire system configuration for the machine.In short, it is very important, and must be able to be found by the kernel at boot time in order for things to work properly.

If your newly configured kernel dies at boot time with an error such as:

then the root filesystem wasn’t found.If you are not using a ramdisk image at boot time, it is usually recommended that you build both the filesystem that you use for your root partition, and the disk controller for that disk, into the kernel, instead of having it as a module.If you use a ramdisk at boot time, you should be safe building these portions as modules.

The following subsections show how to let the kernel find the root filesystem during boot.

Helper Script

As mentioned near the beginning of this chapter, files and directories within sysfs change from one release of the kernel to another.Here is a script that is handy in determining the needed kernel driver and module module name for any device node in the system.It has been developed with the kernel developers responsible for sysfs and should successfully work on all future versions of the 2.6 kernel.

For instance, it makes short work of the previous example, when you had to get all of the proper drivers for the sda block device:

I can also find all of the proper drivers needed for complex things such as USB-toserial devices:

You can download an example file containing this script from the book’s web site, provided in the “How to Contact Us” section of the Preface.

The script follows:

#!/bin/sh
#
# Find all modules and drivers for a given class device.
#
if [ $# != "1" ] ; then

echo echo "Script to display the drivers and modules for a specified sysfs

class device"
echo "usage: $0 <CLASS_NAME>"
echo
echo "example usage:"

echo " $0 sda"
echo "Will show all drivers and modules for the sda block device."
echo
exit 1

fi
DEV=$1
if test -e "$1"; then

DEVPATH=$1

else
# find sysfs device directory for device
DEVPATH=$(find /sys/class -name "$1" | head -1)
test -z "$DEVPATH" && DEVPATH=$(find /sys/block -name "$1" | head -1)
test -z "$DEVPATH" && DEVPATH=$(find /sys/bus -name "$1" | head -1)
if ! test -e "$DEVPATH"; then

echo "no device found"
exit 1

fi
fi
echo "looking at sysfs device: $DEVPATH"
if test -L "$DEVPATH"; then

# resolve class device link to device directory
DEVPATH=$(readlink -f $DEVPATH)
echo "resolve link to: $DEVPATH"

fi

if test -d "$DEVPATH"; then # resolve old-style "device" link to the parent device
PARENT="$DEVPATH";
while test "$PARENT" != "/"; do

if test -L "$PARENT/device"; then
DEVPATH=$(readlink -f $PARENT/device)
echo "follow 'device' link to parent: $DEVPATH"
break

fi
PARENT=$(dirname $PARENT)

done
fi
while test "$DEVPATH" != "/"; do

DRIVERPATH=
DRIVER=
MODULEPATH=
MODULE=
if test -e $DEVPATH/driver; then

DRIVERPATH=$(readlink -f $DEVPATH/driver)
DRIVER=$(basename $DRIVERPATH)
echo -n "found driver: $DRIVER"
if test -e $DRIVERPATH/module; then

MODULEPATH=$(readlink -f $DRIVERPATH/module)
MODULE=$(basename $MODULEPATH)
echo -n " from module: $MODULE"

fi

echo
fi
DEVPATH=$(dirname $DEVPATH)

done

Оставьте свой комментарий !
Ваше имя: Комментарий: Оба поля являются обязательными  Автор   Комментарий к данной статье