Differences between revisions 7 and 8
Revision 7 as of 2009-02-06 06:41:55
Size: 8101
Editor: FranklinPiat
Comment: s/linux-doc-2.6.18/linux-doc-*/
Revision 8 as of 2009-03-16 03:29:50
Size: 8107
Editor: anonymous
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 34: Line 34:
 * [#dev dev]
 * [#udev udev]
 * [#devfs devfs] (obsolete in Debian/Etch)
 * [[#dev|dev]]
 * [[#udev|udev]]
 * [[#devfs|devfs]] (obsolete in Debian/Etch)
Line 39: Line 39:
[[Anchor(dev)]] <<Anchor(dev)>>
Line 55: Line 55:
[[Anchor(udev)]] <<Anchor(udev)>>
Line 62: Line 62:
 * Plans to work with ["DBus"] for GUI notifications.  * Plans to work with [[DBus]] for GUI notifications.
Line 79: Line 79:
Then alter /etc/inittab so that your min/a/mgettys that provide your ["VTs"] point towards "vc/1" instead of "tty1" (no quotes). Then alter /etc/inittab so that your min/a/mgettys that provide your [[VTs]] point towards "vc/1" instead of "tty1" (no quotes).
Line 83: Line 83:
- Jonathan Matthews (jaycee (at) jaycee ["dot"] uklinux {dot} net) - Jonathan Matthews (jaycee (at) jaycee [[dot]] uklinux {dot} net)
Line 98: Line 98:
[[Anchor(devfs)]] <<Anchor(devfs)>>
Line 101: Line 101:
||<style="color:red"> /!\ devfs is obsolete. Debian/Etch uses ["udev"] (except for DebianInstaller)|| ||<style="color:red"> /!\ devfs is obsolete. Debian/Etch uses [[udev]] (except for DebianInstaller)||

Debian GNU/Linux kernel device FAQ

The linux kernel has seen a few different ideas on how users interact with the kernel to gain access to devices such as your fixed disks, terminals, and mice.

The methods have ranged from the dev file system to the latest ideas of udev. Along the way there were other complimentary and conflicting methods.

This FAQ is not a forum for debate over which method is better or worse. There are better forums for that and much bandwidth and time has already been spent. This FAQ is about what support levels exist for the different device interfaces and when you might need to use one or the other.

A brief discussion of the goals and concepts behind each system and a short list of their strengths with as many or less brief points about their shortcommings is also appropriate in this FAQ to help people new to the concepts quickly get up to speed.


What is it?

The dev directory on a system running *nix is the expected location to gain access via file system entries to hardware resources managed by the kernel. It is populated with special files generally of two types; block and character. You can make new files in the dev directory using the mknod command.

If you were using a rescue disk that didn't populate this directory for you, you might need to use mknod to specify that hda is a block device at major number 3 and minor number 0. Then you would need to create the device files for each partition, eg hda1 at major 3 minor 1 and hda2 at major 3 minor 2.

You could have called your special file 'mydisk' if you wanted. The mount command would still work because you specify the device name. Calling it 'mydisk' and then asking for help on #debian or searching the web will return less results than if you had named it 'hda'.

What if you also need access to hdb? That would require a block device file with a major number of 3 and a minor number of 64 of course.

The method of determining the major minor numbers is pretty straight forward if you have the rules at hand, but it's not something that the average user is going to remember. That's why it's nice when the dev directory is prepopulated, or autopopulated.

Pre-populating the dev directory has some downsides. One is that the directory gets pretty large. Debian i386 has over 1000 entries in dev. Most users do not have 1000 devices attached to their system. The dev directory can be intimidating to look through.

Auto-populating the dev directory is more appealing, especially if it works right. In most cases a user doesn't care what file name or major/minor number the kernel and software are using to talk to their printer. They want the printer to print today like it did yesterday without reconfiguring even though they may have plugged it into a different port.

One more concern/issue with the dev directory entries is that the major and minor numbers need to be unique for each device, and we need unique file names. You wouldn't want to have the same entry refer to your first partition on your primary ide disk and to your mouse because they had the same major and minor numbers or the same file name. Coordination of the names and numbers for Linux are done by The Linux Assigned Names and Numbers Authority.

/usr/share/doc/linux-doc-*/Documentation/devices.txt.gz


Device access systems


dev

Strengths

  • Standard
    • Most code is written to use devices as they sit in the dev directory.
  • Simple once set up if you have common devices
  • Many users never need to worry about the dev directory on good distributions like Debian.

Weaknesses

  • Static
    • More entries than you need
    • You may need to create your own entries for new devices

dev is highly supported in Debian Woody. It is the way things are done and things seem to work just fine.


udev

http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ

Strengths

  • Under active development.
  • Builds on the new sysfs and it's hotplug events.
  • Plans to work with ?DBus for GUI notifications.

  • Can use a user defined naming schema to match devfs or the standard dev schema.
  • Supports dynamic major/minor numbering.

Weaknesses

  • New, may not be well supported or debugged.
  • Dynamic model does not support traditional chmod/shell tool permission management. Instead a special additional configfile is neeeded.
  • Mentioning it usually spurs debates ;)

/I don't know what the support for udev is in Debian. Will it be used by default in Sarge if it doesn't release until kernel 2.6 is defacto? I tried udev and didn't get any virtual terminals. Anyone write a 'How to use udev on Debian/Sid'? If not, please include it here./

Here's a brief stab at it:

The udev.rules (/etc/dev/udev.rules) file that the current (0.024-6) udev package installs will cause a boot time failure. (The "no virtual terminals" problem from above).

You need (well, it worked for me ...) to move compat-full.rules to udev.rules (after taking the backup, of course).

Then alter /etc/inittab so that your min/a/mgettys that provide your ?VTs point towards "vc/1" instead of "tty1" (no quotes).

That's all I did, and it works for me. YMMV. Maybe someone else can write about how I should have done it while keeping the vanilla udev rules that the package shipped with.

- Jonathan Matthews (jaycee (at) jaycee ?dot uklinux {dot} net)

OR:

Edit your /etc/inittab to use tty1 though tty6 and not have to use the compatability rules. As an example the it should look something like this:

1:2345:respawn:/sbin/getty 38400 /dev/tty1 2:23:respawn:/sbin/getty 38400 /dev/tty2 3:23:respawn:/sbin/getty 38400 /dev/tty3 4:23:respawn:/sbin/getty 38400 /dev/tty4 5:23:respawn:/sbin/getty 38400 /dev/tty5 6:23:respawn:/sbin/getty 38400 /dev/tty6

- Charles Puffer (cpuffer red-belt org)


devfs

/!\ devfs is obsolete. Debian/Etch uses udev (except for DebianInstaller)

http://www.atnf.csiro.au/people/rgooch/linux/docs/devfs.html

The devfs system designed by Richard Gooch was included in the kernel around 2.3.46 and will likely be there until at least 2.7. It is currently not activly maintained but seems to work well enough for many people.

Strengths

  • Renaming devices to reflect their position and function.
    • hda becomes ide/host0/bus0/target0/lun0/disc
  • Dynamic node creation, so dev reflects what is currently available.
    • Be sure to run devfsd.
  • Dynamic modprobe so modules load when devices are available.

Weaknesses

  • Renaming things breaks some functionality on programs that expect the dev name structure, so you have to put those entries there anyway.
  • Bugs in the system that people haven't stepped up and fixed yet.

The devfs option is compiled into the kernel-image-2.4 packages distributed with Debian. This means that some programs that try to use the proc file system to determine what hardware you have, like noflushd, will expect you to have devfs mounted somewhere.

A quick check to see if devfs is compiled into your system is to cat the partitions file in proc. If the device names are hda1, hda2, etc it is not compiled in. If they are ide/host0/bus0/target0/lun0/part1 than it is.

I've not used devfs on top of dev, anyone who's used it successfully please contribute here.


Discussion

The remainder of this page after the next divider is for open discussion of how these device systems work in Debian. Preferably the discussions can be refactored from time to time and organized under the proper section above, or new on-topic subsections can be created.

Sharing experiances of configuring these device interface systems on various Debian versions and what software worked or was broken is appreciated.