13

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...

Improve this question
3

2 Answers 2

Reset to default
31

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
6
  • 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, 2020 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, 2020 at 13:00
  • OpenBSD still works this way today.
    – JdeBP
    Jun 9, 2020 at 16:30
  • 1
    You can also run a linux system this way even today, albeit it is cumbersome in a world where hotplugging all kinds of devices is common. In the early 2000s, virtual or managed /dev was an exotic thing on linux, especially in the server world.
    – rackandboneman
    Dec 23, 2021 at 6:58
  • 1
    @rackandboneman: Until ending up with device drivers that didn't provide stable minor numbers, I used to manually prepopulate /dev with a snapshot of the dynamic values in case of ending up in a degenerate state. It was convenient when using chroot to fix a broken system.
    – Joshua
    Feb 19, 2022 at 2:00
20

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
5
  • 2
    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, 2020 at 12:44
  • 9
    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.
    – user722
    Jun 8, 2020 at 15:00
  • 5
    @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, 2020 at 3:53
  • You're writing as though mknod is no longer something you can use in this way. Is this so?
    – Героям слава
    May 4, 2022 at 8:25
  • @OmarL, man 2 mknod says, "The system call mknod() creates a filesystem node (file, device special file, or named pipe)..." Notice that "directory" is absent from that list.
    – Solomon Slow
    May 4, 2022 at 13:25

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.