12

UNIX did not have support for virtual file systems (vnodes) until 1986.

  • S.R. Kleiman, “Vnodes: An Architecture for Multiple File System Types in Sun UNIX,” Summer USENIX 1986

I remember this quite clearly: Sun needed vnodes to support NFS. After that, the two ways of creating a virtual file system was as a loop-back NFS server (allowing you to write your file system at the user level), and as a kernel-loaded vnode file system (which required rebuilding the kernel because we didn't have loadable kernel modules).

My question: How did Unix before 1986 implement the /dev file system? I don't have a copy of Lions, but perhaps it is time to buy one...

30

In 1986 (and for a few years after that still), /dev wasn’t handled by a special file system. It was generally a directory on the root file system, and its contents were largely static: a series of device nodes, created by mknod. Many systems had some way of creating the “standard” nodes, for example a Makefile in V7 or MAKEDEV.

Each device node has a type, major number and minor number, and those are mapped to device drivers by the kernel. As long as those assignments were static, and especially as long as device drivers themselves were built into the kernel, there wasn’t much need for a dynamic /dev.

In early versions of the Unix kernel, device access was table-driven; see usr/sys/conf/c.c for both block and character devices. The tables were generated by usr/sys/conf/mkconf.c. You can see them in use, for example, in the openi function.

Even on current systems with dedicated /dev file systems, those are mostly for convenience: device nodes can be created elsewhere, and will work just as well (as long as they’re not on a file system mounted with options which cause device nodes to be ineffective).

| improve this answer | |
  • Yes, I remember MAKEDEV and mknod now. But I don't know how it was handled in the kernel. Was there a big switch statement or something in fs? – vy32 Jun 8 at 12:43
  • It was table-driven in V7, and probably in many subsequent versions (although the table construction itself probably changed). – Stephen Kitt Jun 8 at 13:00
  • OpenBSD still works this way today. – JdeBP Jun 9 at 16:30
18

Just a supplement to what Stephen Kitt already said:

The entries in any directory in a classic Unix file system are hard links that map names to inodes —small fixed-size records in the file system.

There were several different kinds of inode;

  • A "regular file" inode contained information that the OS could use to find the pages of a file.
  • A "directory" inode basically is the same as a regular file, except that the OS treats the file contents as a table of hard links, and it doesn't allow user-mode programs to write the "file."
  • A "device special," inode does not refer to a disk file at all: It contains only a major device number that identifies a device driver compiled in to the kernel, and a minor device number interpreted by the driver. When a program opens a "device special" file, the open file descriptor actually represents a channel connecting the program to the device driver.

There was nothing at all special about the /dev directory. Any user could use the mknod command line utility to create a device special file in any directory where they had write access, and it would work exactly the same as a /dev/foobar device special file with the same major and minor device numbers.

/dev merely was the conventional place for programs to look to find certain device special files. And, of course, like many other "conventional" directories, it conventionally was protected so that only root could make changes there.

| improve this answer | |
  • 1
    Correct, there was nothing special about /dev. Hackers used to put devices in private directories that they owned and that allowed access to raw drives, memory, or whatever. – vy32 Jun 8 at 12:44
  • 8
    The mknod system call also happened to be the way directories were created before the mkdir system call existed. This would create a completely empty directory without . and .. entries. The mkdir command would create the entries manually using the link system call. – Ross Ridge Jun 8 at 15:00
  • 3
    @RossRidge, I remember that too! And we could hide information from file system scanners by unlinking .. and making it a regular directory, and then putting things in it. – vy32 Jun 9 at 3:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.