readme

讲述linux的初始化过程

it to maintain compatibility entries. It is almost certain that you
will require this. Note that the kernel creates a compatibility entry
for the root device, so you don't need initrd.

Note that you no longer need to mount devpts if you use Unix98 PTYs,
as devfs can manage /dev/pts itself. This saves you some RAM, as you
don't need to compile and install devpts. Note that some versions of
glibc have a bug with Unix98 pty handling on devfs systems. Contact
the glibc maintainers for a fix. Glibc 2.1.3 has the fix.

Note also that apart from editing /etc/fstab, other things will need
to be changed if you *don't* install devfsd. Some software (like the X
server) hard-wire device names in their source. It really is much
easier to install devfsd so that compatibility entries are created.
You can then slowly migrate your system to using the new device names
(for example, by starting with /etc/fstab), and then limiting the
compatibility entries that devfsd creates.

MAKE SURE YOU INSTALL DEVFSD BEFORE YOU BOOT A DEVFS-ENABLED KERNEL!

Now that devfs has gone into the 2.3.46 kernel, I'm getting a lot of
reports back. Many of these are because people are trying to run
without devfsd, and hence some things break. Please just run devfsd if
things break. I want to concentrate on real bugs rather than
misconfiguration problems at the moment. If people are willing to fix
bugs/false assumptions in other code (i.e. glibc, X server) and submit
that to the respective maintainers, that would be great.


All the way with Devfs

The devfs kernel patch creates a rationalised device tree. As stated
above, if you want to keep using the old /dev naming scheme,
you just need to configure devfsd appopriately (see the man
page). People who prefer the old names can ignore this section. For
those of us who like the rationalised names and an uncluttered
/dev, read on.

If you don't run devfsd, or don't enable compatibility entry
management, then you will have to configure your system to use the new
names. For example, you will then need to edit your
/etc/fstab to use the new disc naming scheme. If you want to
be able to boot non-devfs kernels, you will need compatibility
symlinks in the underlying disc-based /dev pointing back to
the old-style names for when you boot a kernel without devfs.

You can selectively decide which devices you want compatibility
entries for. For example, you may only want compatibility entries for
BSD pseudo-terminal devices (otherwise you'll have to patch you C
library or use Unix98 ptys instead). It's just a matter of putting in
the correct regular expression into /dev/devfsd.conf.

There are other choices of naming schemes that you may prefer. For
example, I don't use the kernel-supplied
names, because they are too verbose. A common misconception is
that the kernel-supplied names are meant to be used directly in
configuration files. This is not the case. They are designed to
reflect the layout of the devices attached and to provide easy
classification.

If you like the kernel-supplied names, that's fine. If you don't then
you should be using devfsd to construct a namespace more to your
liking. Devfsd has built-in code to construct a
namespace that is both logical and easy to
manage. In essence, it creates a convenient abbreviation of the
kernel-supplied namespace.

You are of course free to build your own namespace. Devfsd has all the
infrastructure required to make this easy for you. All you need do is
write a script. You can even write some C code and devfsd can load the
shared object as a callable extension.


Other Issues

The init programme
Another thing to take note of is whether your init programme
creates a Unix socket /dev/telinit. Some versions of init
create /dev/telinit so that the telinit programme can
communicate with the init process. If you have such a system you need
to make sure that devfs is mounted over /dev *before* init
starts. In other words, you can't leave the mounting of devfs to
/etc/rc, since this is executed after init. Other
versions of init require a named pipe /dev/initctl
which must exist *before* init starts. Once again, you need to
mount devfs and then create the named pipe *before* init
starts.

The default behaviour now is not to mount devfs onto /dev at
boot time for 2.3.x and later kernels. You can correct this with the
"devfs=mount" boot option. This solves any problems with init,
and also prevents the dreaded:

Cannot open initial console

message. For 2.2.x kernels where you need to apply the devfs patch,
the default is to mount.

If you have automatic mounting of devfs onto /dev then you
may need to create /dev/initctl in your boot scripts. The
following lines should suffice:

mknod /dev/initctl p
kill -SIGUSR1 1       # tell init that /dev/initctl now exists

Alternatively, if you don't want the kernel to mount devfs onto
/dev then you could use the following procedure is a
guideline for how to get around /dev/initctl problems:

# cd /sbin
# mv init init.real
# cat > init
#! /bin/sh
mount -n -t devfs none /dev
mknod /dev/initctl p
exec /sbin/init.real $*
[control-D]
# chmod a+x init

Note that newer versions of init create /dev/initctl
automatically, so you don't have to worry about this.

Module autoloading
You will need to configure devfsd to enable module
autoloading. The following lines should be placed in your
/etc/devfsd.conf file:

LOOKUP	.*		MODLOAD


As of devfsd-v1.3.10, a generic /etc/modules.devfs
configuration file is installed, which is used by the MODLOAD
action. This should be sufficient for most configurations. If you
require further configuration, edit your /etc/modules.conf
file.

Mounting root off a devfs device
If you wish to mount root off a devfs device when you pass the
"devfs=only" boot option, then you need to pass in the "root="
option to the kernel when booting. If you use LILO, then you must have
this in lilo.conf:

append = "root=<device>"

Surprised? Yep, so was I. It turns out if you have (as most people
do):

root = <device>


then LILO will determine the device number of  and will write
that device number into a special place in the kernel image before
starting the kernel, and the kernel will use that device number to
mount the root filesystem. So, using the "append" variety ensures that
LILO passes the root filesystem device as a string, which devfs can
then use.

Note that this isn't an issue if you don't pass "devfs=only".

TTY issues
The ttyname(3) function in some versions of the C library makes
false assumptions about device entries which are symbolic links.  The
tty(1) programme is one that depends on this function.  I've
written a patch to libc 5.4.43 which fixes this. This has been
included in libc 5.4.44 and a similar fix is in glibc 2.1.3.


Kernel Naming Scheme

The kernel provides a default naming scheme. This scheme is designed
to make it easy to search for specific devices or device types, and to
view the available devices. Some device types (such as hard discs),
have a directory of entries, making it easy to see what devices of
that class are available. Often, the entries are symbolic links into a
directory tree that reflects the topology of available devices. The
topological tree is useful for finding how your devices are arranged.

Disc Devices

All discs, whether SCSI, IDE or whatever, are placed under the
/dev/discs hierarchy:

	/dev/discs/disc0	first disc
	/dev/discs/disc1	second disc


Each of these entries is a symbolic link to the directory for that
device. The device directory contains:

	disc	for the whole disc
	part*	for individual partitions


CD-ROM Devices

All CD-ROMs, whether SCSI, IDE or whatever, are placed under the
/dev/cdroms hierarchy:

	/dev/cdroms/cdrom0	first CD-ROM
	/dev/cdroms/cdrom1	second CD-ROM


Each of these entries is a symbolic link to the real device entry for
that device.

Tape Devices

All tapes, whether SCSI, IDE or whatever, are placed under the
/dev/tapes hierarchy:

	/dev/tapes/tape0	first tape
	/dev/tapes/tape1	second tape


Each of these entries is a symbolic link to the directory for that
device. The device directory contains:

	mt			for mode 0
	mtl			for mode 1
	mtm			for mode 2
	mta			for mode 3
	mtn			for mode 0, no rewind
	mtln			for mode 1, no rewind
	mtmn			for mode 2, no rewind
	mtan			for mode 3, no rewind


SCSI Devices

To uniquely identify any SCSI device requires the following
information:

  controller	(host adapter)
  bus		(SCSI channel)
  target	(SCSI ID)
  unit		(Logical Unit Number)


All SCSI devices are placed under /dev/scsi (assuming devfs
is mounted on /dev). Hence, a SCSI device with the following
parameters: c=1,b=2,t=3,u=4 would appear as:

	/dev/scsi/host1/bus2/target3/lun4	device directory


Inside this directory, a number of device entries may be created,
depending on which SCSI device-type drivers were installed.

See the section on the disc naming scheme to see what entries the SCSI
disc driver creates.

See the section on the tape naming scheme to see what entries the SCSI
tape driver creates.

The SCSI CD-ROM driver creates:

	cd


The SCSI generic driver creates:

	generic


IDE Devices

To uniquely identify any IDE device requires the following
information:

  controller
  bus		(aka. primary/secondary)
  target	(aka. master/slave)
  unit


All IDE devices are placed under /dev/ide, and uses a similar
naming scheme to the SCSI subsystem.

XT Hard Discs

All XT discs are placed under /dev/xd. The first XT disc has
the directory /dev/xd/disc0.

TTY devices

The tty devices now appear as:

  New name                   Old-name                   Device Type
  --------                   --------                   -----------
  /dev/tts/{0,1,...}         /dev/ttyS{0,1,...}         Serial ports
  /dev/cua/{0,1,...}         /dev/cua{0,1,...}          Call out devices
  /dev/vc/{0,1,...}          /dev/tty{1...63}           Virtual consoles
  /dev/vcc/{0,1,...}         /dev/vcs{1...63}           Virtual consoles
  /dev/pty/m{0,1,...}        /dev/ptyp??                PTY masters
  /dev/pty/s{0,1,...}        /dev/ttyp??                PTY slaves


RAMDISCS

The RAMDISCS are placed in their own directory, and are named thus:

  /dev/rd/{0,1,2,...}


Meta Devices

The meta devices are placed in their own directory, and are named
thus:

  /dev/md/{0,1,2,...}


Floppy discs

Floppy discs are placed in the /dev/floppy directory.

Loop devices

Loop devices are placed in the /dev/loop directory.

Sound devices

Sound devices are placed in the /dev/sound directory
(audio, sequencer, ...).


Devfsd Naming Scheme

Devfsd provides a naming scheme which is a convenient abbreviation of
the kernel-supplied namespace. In some
cases, the kernel-supplied naming scheme is quite convenient, so
devfsd does not provide another naming scheme. The convenience names
that devfsd creates are in fact the same names as the original devfs
kernel patch created (before Linus mandated the Big Name Change).

In order to configure devfsd to create these convenience names, the
following lines should be placed in your /etc/devfsd.conf:

REGISTER	.*		MKNEWCOMPAT
UNREGISTER	.*		RMNEWCOMPAT

This will cause devfsd to create (and destroy) symbolic links which
point to the kernel-supplied names.

SCSI Hard Discs

All SCSI discs are placed under /dev/sd (assuming devfs is
mounted on /dev). Hence, a SCSI disc with the following
parameters: c=1,b=2,t=3,u=4 would appear as:

	/dev/sd/c1b2t3u4	for the whole disc
	/dev/sd/c1b2t3u4p5	for the 5th partition
	/dev/sd/c1b2t3u4p5s6	for the 6th slice in the 5th partition


SCSI Tapes

All SCSI tapes are placed under /dev/st. A similar naming
scheme is used as for SCSI discs. A SCSI tape with the
parameters:c=1,b=2,t=3,u=4 would appear as:

	/dev/st/c1b2t3u4m0	for mode 0
	/dev/st/c1b2t3u4m1	for mode 1
	/dev/st/c1b2t3u4m2	for mode 2
	/dev/st/c1b2t3u4m3	for mode 3
	/dev/st/c1b2t3u4m0n	for mode 0, no rewind
	/dev/st/c1b2t3u4m1n	for mode 1, no rewind
	/dev/st/c1b2t3u4m2n	for mode 2, no rewind
	/dev/st/c1b2t3u4m3n	for mode 3, no rewind


SCSI CD-ROMs

All SCSI CD-ROMs are placed under /dev/sr. A similar naming
scheme is used as for SCSI discs. A SCSI CD-ROM with the
parameters:c=1,b=2,t=3,u=4 would appear as:

	/dev/sr/c1b2t3u4


SCSI Generic Devices

All SCSI CD-ROMs are placed under /dev/sg. A similar naming
scheme is used as for SCSI discs. A SCSI generic device with the
parameters:c=1,b=2,t=3,u=4 would appear as:

	/dev/sg/c1b2t3u4