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.