Helio/mknod

From FBSD_tips

This question comes up alot, 'How come I can't use MAKEDEV anymore?' or 'when I try to mknod null, I get an error?'

[edit] The short answer

You can't use mknod on FreeBSD anymore, period.

[edit] The long answer:

Alas, poor SPECFS! -- I knew him, Horatio; A filesystem of infinite
jest, of most excellent fancy: he hath taught me lessons a thousand
times; and now, how abhorred in my imagination it is! my gorge rises
at it.  Here were those hacks that I have curs'd I know not how
oft.  Where be your kludges now? your workarounds? your layering
violations, that were wont to set the table on a roar?
- phk@freebsd.org - Fri Oct 22 09:59:36 2004 UTC 

SPECFS (the backbone of device nodes) was a horrible kludge and hack, simply because, it was irrelevant

[edit] History

Way back in the olden days, when UNIX was first created, it had the novel idea of treating devices the same as normal files. This was originally done by 'reserving' inode numbers for different devices, and compiling the mappings into the kernel (for example, first teletype was inode 2, second teletype was inode 3, first fixed head disk was inode 4, etc). Although at the time, there was no 'device detection' and it had to be compiled into the kernel anyway, so everything was good.

After the first few UNIX installations outside of Bell Labs, it became clear that this wouldn't work. one installation would use inode 3 for a teletype, while another installation would use 3 for a tape drive. So, devices were given a seperate ID instead, that wasn't related to inodes at all. Then everything was good.

Fast forward a few years, now we have a situation where when the machine is booted, it could have 1 hard drive, or 6, or 0. So a few people decided to split it, into major device numbers, and minor device numbers. The device driver or type was given a major number, and each instance was given a minor number. Then everything was good.

Fast forward more years, and FreeBSD implements NewBus. NewBus allows different bus attachments, a hierarchy, and hot plugging support (for most things). Suddenly, you can plug something into a running machine, and get a new device. each one was given an id internally, that was guaranteed unique, yet the kernel still had a statically compiled list of major id numbers.

A few years later, devfs (the current implementation) was written. Each device driver had a name space (named after the driver, no less), and when you accessed /dev/ad0, instead of checking what ad0's major id is, to find the driver, then the minor id, and the driver, and hoping to hell it matches up to the in kernel id you think it did; when you access /dev/ad0, it mapped it directly to the in-kernel id.

The problem, is that specfs was still being consulted, and was a viable option. Even though there was a more efficient and less error prone implementation, the major id list was still being used. Until, it was decided that it had been long enough, and finally, finally it was removed from the kernel, never to be seen again.