The Answer Gang

File with Device Information

System Inventory File?

From Paul Haigh on Thu, 17 Aug 2000

Answered By: Jim Dennis

Hi

I once looked at a file in linux which had a listing of all devices found during the installation process. For example it listed the Video card of the PC I had just installed. I was using Redhat 6.0. What is the name of this file? Where is it? I for the life of me can't remember. nor find it I thought it was in /proc but that isn't correct. Sorry to be so forgetful. Thanks, your help is appreciated.

Paul

Hmm. The installation process is specific to each distribution. So that list would depend on whether you were using Red Hat, Debian, Mandrake, etc. I also don't know what filename it would be under, nor which distributions and versions store this information.

Indeed the whole issue is rather more complicated than you question implies.

A Linux kernel does a certain amount of probing to find devices. This depends on the list of device drivers that were linked into the kernel. Obviously if you leave a device driver out of a kernel, that kernel won't probe for those devices. It's not as obvious, but the kernel also won't probe for devices for which the drivers were compiled as modules. To be more precise the kernel won't probe for any device until its device driver is loaded.

So, you may find that some devices are completely ignored (undetected) until you've loaded the appropriate kernel module, or rebuilt a kernel with the necessary support.

Some devices may also go undetected because they are set at some set of addresses (I/O or memory mapping) that is unusual for them, or is likely to be in conflict with other devices. The kernel doesn't scan the entire I/O address space for each card. Not only would that be slow, it would probably hang the system. Devices must be accessed using the correct protocols --- and some of those will go into a catatonic state, or will lock up the whole system if they are accessed incorrectly. (The Linux kernel avoids most of these "dangerous regions" by default, and only looks for most devices in the common places).

All of this much less of a problem in recent years. Most platforms have adopted the PCI bus which has standard methods for discovering and identifying devices, and for avoided conflicts among them. In essence your PCI bus is a network of semi-intelligent adapter cards interoperating over the PCI "protocol." This has always been true of SCSI as well (though with SCSI we still need to manually set unique device IDs). USB and firewire are also much more intelligent and less problematic than the old ISA PC bus.

That brings us back to the question at hand. How do we determine what hardware is installed in a PC without opening the case and getting the (all-too-often unavailable and/or inadequate) specification sheets.

You can start with /var/log/dmesg. This file should have a copy of all the messages that your kernel printed during the initial boot process.

Then take a look at /proc/pci. As you probably know, the /proc directory is usually a mount point for a special "virtual" filesystem. The various "files" and directories that appear under /proc don't exist as real files on any disk drive. They are sort of like a "RAMdisk" except that they don't take up memory in the same way. The "files" under /proc are actually a representation of the kernel's state or of specific data structures as they are maintained by the kernel. The entries under /proc are dynamic --- the contents of these "files" will appear to change as the state of the kernel changes. (In fact under the /proc/sys directory tree there are many nodes or "files" which can be modified by the system administrator to change the state of the kernel).

After looking at /proc/pci, peruse /proc/interrupts and /proc/ioports and explore some of the other files thereunder. Note: All of the /proc/XXXX dircectories, where XXXX is a number are "processes." These represent all of the state about each process that is accessible to programs like 'ps' and 'top'. The original purpose of the /proc directory in UNIX (and Linux) was to allow for a cleaner interface to process data and to allow programs like 'ps' to be run without requiring them to have 'root' access. The Linux /proc goes beyond that to contain lots of information about the process state.

In the next version of the kernel (2.4.x) you'll see yet another way to discover hardware that's installed in your system. The 2.4.x kernels will support a feature called "devfs" (a "device filesystem"). This is similar to /proc in that it's virtual and that it dynamically represents the state of a system as the kernel "sees" it. There are significant differences. However, we'll skip further comparison of /devfs to /proc.

What's more interesting here is a comparison of /devfs to the traditional /dev/ directory. The /dev/ directory normally contains a set of "nodes" (basically special empty files with funny numbers instead of a filesize). Those "nodes" have all the attributes of regular files (owners, group associations, permissions, and dates. They come in two types, character and block. On a typical UNIX or Linux system the /dev/ directory contains a list of all the common devices that might be on a system. This list can be quite large (over a thousand entries on my laptop). Obviously no system actually has all of those devices. However, most systems contain the entries for them as a bit of bookkeeping baggage.

With /devfs we'll see only a list of those devices which were detected by the kernel. As we load kernel modules we'll see new nodes appear under /devfs. It's also possible to manually create nodes under /devfs. Those will persist until the next reboot. Thus it may be necessary for some systems to restore a list of device nodes under their /devfs directory every time you reboot. (That would probably be most easily done by simply adding an rc.* script to extract a .tar or cpio file into the newly mounted /devfs directory).

Of course this new model won't just appear overnight. It will be interesting to see how the distribution maintainers (Caldera, TurboLinux, etc) each choose to integrate this new feature into their offerings.

Meanwhile there are things like Red Hat's "kudzu" package which tries to detect newly added hardware when it is first installed into your system (upon the next reboot). That may also help you.

Sometimes, you'll probably still have to grab a screw driver and pop open the case. Worse, sometimes you probably will have no practical way of knowing about some of the hardware that's in your systems. PC manufacturers have gotten lax about providing technical documentation with their equipment.

Copyright © 2000, James T. Dennis
Published in the Linux Gazette Issue 57 September 2000

HTML transformation by Heather Stern of Tuxtops, Inc., http://www.tuxtops.com/

1   2   3   4   5   6   7