readme

讲述linux的初始化过程

IDE Hard Discs

All IDE discs are placed under /dev/ide/hd, using a similar
convention to SCSI discs. The following mappings exist between the new
and the old names:

	/dev/hda	/dev/ide/hd/c0b0t0u0
	/dev/hdb	/dev/ide/hd/c0b0t1u0
	/dev/hdc	/dev/ide/hd/c0b1t0u0
	/dev/hdd	/dev/ide/hd/c0b1t1u0


IDE Tapes

A similar naming scheme is used as for IDE discs. The entries will
appear in the /dev/ide/mt directory.

IDE CD-ROM

A similar naming scheme is used as for IDE discs. The entries will
appear in the /dev/ide/cd directory.

IDE Floppies

A similar naming scheme is used as for IDE discs. The entries will
appear in the /dev/ide/fd directory.

XT Hard Discs

All XT discs are placed under /dev/xd. The first XT disc
would appear as /dev/xd/c0t0.


SCSI Host Probing Issues

Devfs allows you to identify SCSI discs based in part on SCSI host
numbers. If you have only one SCSI host (card) in your computer, then
clearly it will be given host number 0. Life is not always that easy
is you have multiple SCSI hosts. Unfortunately, it can sometimes be
difficult to guess what the probing order of SCSI hosts is. You need
to know the probe order before you can use device names. To make this
easy, there is a kernel boot parameter called "scsihosts". This allows
you to specify the probe order for different types of SCSI hosts. The
syntax of this parameter is:

scsihosts=<name_1>:<name_2>:<name_3>:...:<name_n>

where <name_1>,<name_2>,...,<name_n> are the names
of drivers used in the /proc filesystem. For example:

    scsihosts=aha1542:ppa:aha1542::ncr53c7xx


means that devices connected to

- first aha1542 controller   - will be c0b#t#u#
- first parallel port ZIP    - will be c1b#t#u#
- second aha1542 controller  - will be c2b#t#u#
- first NCR53C7xx controller - will be c4b#t#u#
- any extra controller       - will be c5b#t#u#, c6b#t#u#, etc
- if any of above controllers will not be found - the reserved names will
  not be used by any other device.
- c3b#t#u# names will never be used


You can use ',' instead of ':' as the separator character if you
wish. I have used the devfsd naming scheme
here.

Note that this scheme does not address the SCSI host order if you have
multiple cards of the same type (such as NCR53c8xx). In this case you
need to use the driver-specific boot parameters to control this.

-----------------------------------------------------------------------------


Device drivers currently ported

- All miscellaneous character devices support devfs (this is done
  transparently through misc_register())

- SCSI discs and generic hard discs

- Character memory devices (null, zero, full and so on)
  Thanks to C. Scott Ananian <[e-mail]>

- Loop devices (/dev/loop?)
 
- TTY devices (console, serial ports, terminals and pseudo-terminals)
  Thanks to C. Scott Ananian <[e-mail]>

- SCSI tapes (/dev/scsi and /dev/tapes)

- SCSI CD-ROMs (/dev/scsi and /dev/cdroms)

- SCSI generic devices (/dev/scsi)

- RAMDISCS (/dev/ram?)

- Meta Devices (/dev/md*)

- Floppy discs (/dev/floppy)

- Parallel port printers (/dev/printers)

- Sound devices (/dev/sound)
  Thanks to Eric Dumas <[e-mail]> and
  C. Scott Ananian <[e-mail]>

- Joysticks (/dev/joysticks)

- Sparc keyboard (/dev/kbd)

- DSP56001 digital signal processor (/dev/dsp56k)

- Apple Desktop Bus (/dev/adb)

- Coda network file system (/dev/cfs*)

- Virtual console capture devices (/dev/vcc)
  Thanks to Dennis Hou <[e-mail]>

- Frame buffer devices (/dev/fb)

- Video capture devices (/dev/v4l)


-----------------------------------------------------------------------------


Allocation of Device Numbers

Devfs allows you to write a driver which doesn't need to allocate a
device number (major&minor numbers) for the internal operation of the
kernel. However, there are a number of userspace programmes that use
the device number as a unique handle for a device. An example is the
find programme, which uses device numbers to determine whether
an inode is on a different filesystem than another inode. The device
number used is the one for the block device which a filesystem is
using. To preserve compatibility with userspace programmes, block
devices using devfs need to have unique device numbers allocated to
them. Furthermore, POSIX specifies device numbers, so some kind of
device number needs to be presented to userspace.

The simplest option (especially when porting drivers to devfs) is to
keep using the old major and minor numbers. Devfs will take whatever
values are given for major&minor and pass them onto userspace.

Alternatively, you can have devfs choose unique device numbers for
you. When you register a character or block device using
devfs_register you can provide the optional
DEVFS_FL_AUTO_DEVNUM flag, which will then automatically allocate a
unique device number (the allocation is separated for the character
and block devices).

This device number is a 16 bit number, so this leaves plenty of space
for large numbers of discs and partitions. This scheme can also be
used for character devices, in particular the tty devices, which are
currently limited to 256 pseudo-ttys (this limits the total number of
simultaneous xterms and remote logins).  Note that the device number
is limited to the range 36864-61439 (majors 144-239), in order to
avoid any possible conflicts with existing official allocations.

Please note that using dynamically allocated block device numbers may
break the NFS daemons (both user and kernel mode), which expect dev_t
for a given device to be constant over the lifetime of remote mounts.

A final note on this scheme: since it doesn't increase the size of
device numbers, there are no compatibility issues with userspace.

-----------------------------------------------------------------------------


Questions and Answers


Making things work
Alternatives to devfs



Making things work

Here are some common questions and answers.



Devfsd is not managing all my permissions

Make sure you are capturing the appropriate events. For example,
device entries created by the kernel generate REGISTER events,
but those created by devfsd generate CREATE events.


Devfsd is not capturing all REGISTER events

See the previous entry: you may need to capture CREATE events.


X will not start

Make sure you followed the steps 
outlined above.


Why don't my network devices appear in devfs?

This is not a bug. Network devices have their own, completely separate
namespace. They are accessed via socket(2) and
setsockopt(2) calls, and thus require no device nodes. I have
raised the possibilty of moving network devices into the device
namespace, but have had no response.





Alternatives to devfs

I've attempted to collate all the anti-devfs proposals and explain
their limitations. Under construction.


Why not just pass device create/remove events to a daemon?

Here the suggestion is to develop an API in the kernel so that devices
can register create and remove events, and a daemon listens for those
events. The daemon would then populate/depopulate /dev (which
resides on disc).

This has several limitations:


it only works for modules loaded and unloaded (or devices inserted
and removed) after the kernel has finished booting. Without a database
of events, there is no way the daemon could fully populate
/dev


if you add a database to this scheme, the question is then how to
present that database to user-space. If you make it a list of strings
with embedded event codes which are passed through a pipe to the
daemon, then this is only of use to the daemon. I would argue that the
natural way to present this data is via a filesystem (since many of
the events will be of a hierarchical nature), such as devfs.
Presenting the data as a filesystem makes it easy for the user to see
what is available and also makes it easy to write scripts to scan the
"database"


the tight binding between device nodes and drivers is no longer
possible (requiring the otherwise perfectly avoidable
table lookups)


you cannot catch inode lookup events on /dev which means
that module autoloading requires device nodes to be created. This is a
problem, particularly for drivers where only a few inodes are created
from a potentially large set


this technique can't be used when the root FS is mounted
read-only




Just implement a better scsidev

This suggestion involves taking the scsidev programme and
extending it to scan for all devices, not just SCSI devices. The
scsidev programme works by scanning /proc/scsi

Problems:


the kernel does not currently provide a list of all devices
available. Not all drivers register entries in /proc or
generate kernel messages


there is no uniform mechanism to register devices other than the
devfs API


implementing such an API is then the same as the
proposal above




Put /dev on a ramdisc

This suggestion involves creating a ramdisc and populating it with
device nodes and then mounting it over /dev.

Problems:



this doesn't help when mounting the root filesystem, since you
still need a device node to do that


if you want to use this technique for the root device node as
well, you need to use initrd. This complicates the booting sequence
and makes it significantly harder to administer and configure. The
initrd is essentially opaque, robbing the system administrator of easy
configuration


insufficient information is available to correctly populate the
ramdisc. So we come back to the
proposal above to "solve" this


a ramdisc-based solution would take more kernel memory, since the
backing store would be (at best) normal VFS inodes and dentries, which
take 284 bytes and 112 bytes, respectively, for each entry. Compare
that to 72 bytes for devfs




Do nothing: there's no problem

Sometimes people can be heard to claim that the existing scheme is
fine. This is what they're ignoring:


device number size (8 bits each for major and minor) is a real
limitation, and must be fixed somehow. Systems with large numbers of
SCSI devices, for example, will continue to consume the remaining
unallocated major numbers. USB will also need to push beyond the 8 bit
minor limitation


simplying increasing the device number size is insufficient. Apart
from causing a lot of pain, it doesn't solve the management issues
of a /dev with thousands or more device nodes


ignoring the problem of a huge /dev will not make it go
away, and dismisses the legitimacy of a large number of people who
want a dynamic /dev


the standard response then becomes: "write a device management
daemon", which brings us back to the
proposal above



-----------------------------------------------------------------------------


Other resources



Douglas Gilbert has written a useful document at

http://www.torque.net/sg/devfs_scsi.html which
explores the SCSI subsystem and how it interacts with devfs


Douglas Gilbert has written another useful document at

http://www.torque.net/scsi/scsihosts.html which
discusses the scsihosts= boot option


Douglas Gilbert has written yet another useful document at

http://www.torque.net/scsi/linux_scsi_24/ which
discusses the Linux SCSI subsystem in 2.4.


Johannes Erdfelt has started a discussion paper on Linux and
hot-swap devices, describing what the requirements are for a scalable
solution and how and why he's used devfs+devfsd. Note that this is an
early draft only, available in plain text form at:

http://johannes.erdfelt.com/hotswap.txt.
Johannes has promised a HTML version will follow.