Device Filesystem
The device filesystem is a hotly debated feature that many people
think Linux needs. It is often known as devfs. FreeBSD has already
implemented the devfs, though it is still considered experimental.
The basic idea is that /dev should be more like /proc.
Here are some of the issues related to devfs use and implementation.
The BSD version
They seem to allocate 32-bit device numbers dynamically.
They will never run out of device numbers for anything
because they do not need the sparse MAJOR:MINOR allocation
that a normal system would use.
Inode storage
Mostly this does not matter, but on a boot disk with ext2
the /dev storage requirements can be significant.
Billions of devices
Dynamic device numbering can be more practical because it lets
devices with one major number spill over into the next when
more devices are required. The current sparse allocation is
wasteful.
Backup
There are some tools that do not properly backup device files.
For example, you might want to use a backup device Linux does
not support. You could export the Linux filesystem, but the
foreign system might not support backing up devices.
Newbie confusion
New Linux users sometimes think that Linux detected a modem because
there is a modem entry in /dev. That is wrong of course, but it is
not a dumb mistake either. We should not torture newbies.
Information
If /dev worked the way a newbie might expect, then even experts
would benefit. It would be great to be able to do "ls /dev"
to see what is available. With the traditional setup, it is difficult
to determine what devices actually work and "ls /dev" will
scroll right off the screen even if only 100 devices are used.
Directory lookups
Linux systems often have 1000 entries in /dev. Directory lookups
on the ext2 filesystem are linear, so it is very bad to have so
many entries. Directory lookups are done every time a program
allocates a pty (telnetd, xterm, screen, emacs...), finds out a
tty name (ps, top, SVGA programs), opens /dev/null (many things)...
These huge linear directory lookups slow down Linux.
Time stamps
Whenever a device is used, an update of the atime (access time) is
required. Every update means a disk head seek, which reduces Linux
disk performance.
Read-only filesystems
The FSSTND (Linux filesystem standard document) suggests the possibility
of a read-only root filesystem. Read-only filesystems help reduce the
chance that mistakes, crashes, and crackers (evil hackers) might damage
something. The Linux root filesystem can not be read-only because the
normal /dev must be read-write to allow tty ownership changes. With the
devfs, the root filesystem can be read-only.
The current /dev could be trouble for Linux embedded in ROM.
Maintenance
Maintenance of the /dev doesn't occur frequently, but when it
does then it's up to the system administrator to resolve the
synchronisation between major/minor numbers the kernel has the
drivers at and what has been stored on the filesystem.
For those that don't see a problem here, consider that many
versions of Slackware had hdc* and hdd* messed up.
With a devfs, Linux device names become better standardized.
Umsdos
The umsdos filesystem (Linux over DOS) suffers from excessive overhead.
Device files and symbolic link storage is awkward and very slow. The
devfs would eliminate the overhead and reduce the umsdos requirements.
NTFS
With a devfs, NTFS could be used as the root filesystem. The NT
filesystem supports POSIX file storage, but does not support device
files. Linux support for NTFS is in development, but NTFS will not
be useable as a root filesystem until the normal /dev can be avoided.
PTY security
When a pty is needed, root must change the owner. When that pty is
not needed anymore, root must change the owner back again. There are
problems with that method, because it means that many programs should
be setuid root. Emacs shell windows leave a security hole because the
pty owner never gets changed. Many programs can fail to change the pty
owner back.
With devfs, the kernel can chown ptys back to root when a process
does not need them anymore. The kernel might be able to let normal
users chown their own pty or it might perform the chown automatically.
Per-user devices
The devfs could appear to contain only those devices that the user
has permission for. The devfs could always seems to have just the
next available pty instead of all the ptys in use. There are many
possibilities that might increase security, increase speed, and
reduce "ls /dev" output.
/proc
The devfs might be able to share code with the procfs, but it would
be bad to make /dev a link to /proc/dev for performance reasons.
There is also the (slim) possibility that Linux will migrate to
the Solaris or Digital Unix /proc for compatibility.
Kernel bloating
There are always tradeoffs. When Linus created Linux, he chose the
386 as the minimum hardware. While it would be nice to run standard
Linux on the 286, doing so would mean the rest of us must suffer.
Those people who can't use devfs because of memory limitations should
keep using the unofficial 1.2.14 with a.out and the minix filesystem.
(If you can't run devfs, you don't want to run Linux 2.0 either...)
Look at what ID software does: Quake requires a Pentium with about
16 MB of RAM. They know that designing software for obsolete hardware
will make the software obsolete. BTW, NT 4.0 needs a Pentium with
32 MB of RAM, and even Microsoft admits to a 486 with 12 MB of RAM.
Loadable modules
Currently when an access to a /dev file occurs, and the driver
associated with the major/minor numbers doesn't exist, the kernel
asks kerneld to load it. This scheme won't work with missing dev
entries. Instead of by number, the devfs can attempt a kerneld module
request by name and only return ENOENT if that fails.
Modules (and compiled in drivers) could register names to be placed
in /dev, eg floppy.o could register fd0, fd0...
An advantage with this is that you would only have dev entries
for devices you currently have loaded.
Symlinks
Symlinks can be stored. There should be no problems, though symlinks
may need to be put in a script that runs at boot.
Removal
Removed device files can be removed in the same way, though perhaps
it is good to prevent removal.
Wild idea
Virtual directories including procfs and devfs can be mounted on /
initially. Then the kernel would perform some kind of transparent
mount for the root filesystem (without a /dev /proc .. ) on top of /.
That might make the initrd stuff work better because there would be
no need to mount, unmount, and remount /proc and /dev.