is a program that will create the devices in /dev used to interface
with drivers in the kernel.
Note that programs giving the error ``ENOENT: No such file or
directory'' normally means that the device file is missing, whereas
``ENODEV: No such device'' normally means the kernel does not have the
driver configured or loaded.
Print out version and exit.
Always create devices, even if they already exist and have the proper
permissions and file context. The default behavior is to only (re-)create
device nodes which appear to be missing or whose permissions differ from the
Create no more than the specified number of devices for any specification in a
Do not actually update the devices, just print the actions that would be
Create symlinks, directories, and sockets belonging to the current user,
and print out the list of devices which would be created in a format
which is understood by RPM.
Do not actually update the devices, just print the actions that would be
performed in a format which can be fed to a shell.
Create the devices under directory instead of the default (usually
Compute file contexts for device creation as if the directory specified for the
-d flag were the specified directory. This is useful if the -d flag is being
used to populate a chrooted device directory.
Print the ownership and permissions for devices instead of creating them. The
information is formatted for use by udev.
Create exactly the named device. By default, device names which have the
specified device name as the initial portion of their name are also created.
For example, specifying "tty" will also trigger the creation of "tty1", "tty2",
and so on.
Be verbose. Print out the actions as they are performed. This is the
same output as produced by the -n option.
Ignore errors parsing configuration files.
Since there is currently no standardization in what names are used for
system users and groups, it is possible that you may need to modify
MAKEDEV's configuration files to reflect your site's settings.
Certain devices are required for minimal functionality. These are:
- access to physical memory;
- null device (infinite sink);
- access to I/O ports;
- null byte source (infinite source);
- symlink to /proc/kcore (for kernel debugging);
- always returns ENOSPACE on write;
- to access the controlling tty of a process.
This creates the devices associated with the console. These are the virtual
terminals ttyx, where x can be from 0 though 63. The device
tty0 is the currently active VT, and is also known as console.
For each VT, there are two devices: vcsx and vcsax,
which can be used to generate screen-dumps of the VT (vcsx is just the
text, and vcsax includes the attributes).
Each possible argument will create a bank of 16 master and slave
pairs. The current kernel (1.2) is limited to 64 such pairs.
The master pseudo-terminals are
and the slaves are
Standard parallel ports. The devices are created
The various bus mice devices. This creates the following devices:
(Logitech bus mouse),
(Microsoft Inport bus mouse) and
(ATI XL bus mouse) and
Floppy disk devices. The device
is the device which autodetects the format, and the additional devices are
fixed format (whose size is indicated in the name).
The other devices are named as
The single letter
identifies the type of floppy disk (d = 5.25" DD, h = 5.25" HD, D = 3.5"
DD, H = 3.5" HD, E = 3.5" ED). The number
represents the capacity of that format in K. Thus the standard formats
For more information see Alain Knaff's fdutils package.
are floppy disks on the first controller, and devices
are floppy disks on the second controller.
AT hard disks. The device
provides access to the whole disk, with the partitions being
The four primary partitions are
with the logical partitions being numbered from
(A primary partition can be made into an extended partition, which can hold
4 logical partitions).
By default, only the devices for 4 logical partitions are made. The
others can be made by uncommenting them.
Drives hda and hdb are the two on the first controller. If using the new
IDE driver (rather than the old HD driver), then hdc and hdd are the two
drives on the secondary controller. These devices can also be used to
acess IDE CDROMs if using the new IDE driver.
XT hard disks. Partitions are the same as IDE disks.
sd[a-z], sd[a-c][a-z], sdd[a-x]
SCSI hard disks. The partitions are similar to the IDE disks, but there
is a limit of 11 logical partitions
This is to allow there to be 128 SCSI disks.
Loopback disk devices. These allow you to use a regular file as a
block device. This means that images of filesystems can be mounted,
and used as normal. This creates 16 devices loop0 through loop15.
SCSI tapes. This creates the rewinding tape device
and the non-rewinding tape device
QIC-80 tapes. The devices created are
Floppy driver tapes (QIC-117). There are 4 methods of access depending on
the floppy tape drive. For each of access methods 0, 1, 2 and 3, the
(non-rewinding) are created. For compatability, devices
are symlinks to
SCSI CD players.
Sony CDU-31A CD player.
Mitsumi CD player.
Sony CDU-535 CD player.
LMS/Philips CD player.
Sound Blaster CD player. The kernel is capable of supporting 16 CDROMs,
each of which is accessed as
These are assigned in groups of 4 to each controller.
is a symlink to
Logitech ScanMan32 & ScanMan 256.
Mustek M105 Handscanner.
A4Tek Color Handscanner.
This creates the audio devices used by the sound driver. These include
Generic SCSI devices. The devices created are
These allow arbitary commands to be sent to any SCSI device. This allows for
querying information about the device, or controlling SCSI devices that
are not one of disk, tape or CDROM (e.g. scanner, CD-R, CD-RW).
To allow an arbitary program to be fed input from file descriptor
as the file name. This also creates
(Note, these are just symlinks into /proc/self/fd).
Devices (and symlinks) needed by the IBCS2 emulation.
Devices for power management.
Linux used to have devices in /dev for controlling network devices, but
that is no longer the case. To see what network devices are known by the
kernel, look in /proc/net/dev.
Note that the list of devices above is not exhaustive. MAKEDEV can create
more devices nodes. Its aim is to be able to create everything listed in the
devices.txt file distributed with Linux 2.4.
MAKEDEV doesn't actually know anything about devices. It reads all of the
information from files stored in /etc/makedev.d. MAKEDEV will read any
and all files in the subdirectory, skipping over subdirectories, symbolic
links, and device nodes, processing lines in the files like so:
mode owner group major minor inc count fmt [base]
count devices will be created, with permissions set to mode and
owned by owner and group. The first device will be named fmt,
and additional devices will be created if count is larger than 1.
If fmt contains a C-style formatting string, it will be filled with the
sum of base and zero. Subsequent devices will be filled with the sum of
base and n * inc, where n is the order this device is
being created in. If the format string did not already include a format
specifier, a "%d" will automatically be appended to it to make this work.
A symbolic link pointing to target named linkname will be created.
Any commands that create devices for alias will also include devices that
would be crated for value.
Indicates a macro which can be referenced as $macro in subsequent
In the event that the set of configuration files contains multiple rules for a
given device name, MAKEDEV will use all of them. The end result is typically
that the last rule given (either by virtue of being listed below all other
matching rules in the same file, or by being listed in a file which is read
after all others which contain alternate rules) will apply. MAKEDEV reads the
set of configuration files in sorted order, so this misfeature can be exploited
Let's hope not. If we're lucky, any problems we'll find will be confined to
the configuration files, which were written by examining the devices.txt file.
If your system uses udev, conflicts between devices.txt and the in-kernel data
which udev uses for naming devices may crop up. If you find any bugs, please
file them in the bug database at http://bugzilla.redhat.com/ against the
Nalin Dahyabhai, based largely on work done by
Michael K. Johnson.