unix/BSDForcedNetworkNaming written at 01:18:40; Add Comment
Defending Berkeley's forced choice in network device naming
Despite what I wrote back in the last entry, I actually think that BSD's choice to not put network devices in the filesystem is defensible and in many ways was the best option they had. Explaining why requires rewinding back to the pre-BSD days of Unix.
In the days of V7 and earlier, devices on Unix were simple. You had
block special devices for hardware like hard drives that you read from
and wrote to in fixed size blocks, and character special devices for
hardware such as serial ports that you could do IO to either a character
at a time or (sometimes) in variable block sizes. When you needed to
manipulate parameters of the hardware like the serial port speed, you
generally garnished this basic model with some
(The tape drivers famously used portions of the device minor number to
say whether or not you wanted the drive to rewind automatically and what
block size they should use. This led to a profusion of
What this model doesn't cope well with is what I'll call 'control'
devices, devices that you use to manipulate parameters instead of
reading and writing data. The traditional approach was to make such
things character devices so that you could open them and then use a lot
(It is worth remembering that in 1980, there was no idea of a 'virtual filesystem layer' that unified disparate filesystem types; there was just the filesystem, singular and period. Sun implemented the first Unix VFS in the mid 1980s for NFS.)
So there is the Berkeley CSRG,
designing the BSD network layer and realizing that they needed network
devices. Network devices (in the sense of things like
So the CSRG had two real choices. If they wanted network devices to
live in the filesystem, they were going to have to add a third type of
device (either 'network devices' or 'control devices'). This would have
required changes all over the system, from the filesystem up through the
kernel to utilities and even things like
Or CSRG could give network devices an entirely independent namespace, outside of the filesystem. The only programs that would have to know about this namespace were network management programs (which CSRG had to write anyways).
In hindsight, I'm not too surprised that CSRG decided to take the second option. You can criticize them for deviating from the spirit of Unix in this (as they did with any number of other things), but on the other hand in many ways they were under very business-like pressures to deliver results in the form of a Unix with networking.
(After all, that's what they'd gotten grants to do. DARPA did not fund CSRG to conduct leading edge research on how to integrate networking into the fundamental Unix vision; they funded CSRG to get IP into a version of Unix. Or such is my understanding, at least.)
Sidebar: why having actual control devices doesn't get you much
Since you can't do regular IO to 'control' devices, you can't leverage
other Unix tools to work with them. The drawback of using
This may be one reason that Research Unix did not have a separate category for such 'control' devices to start with.
(To a certain extent V7 used plain
* * *
Atom feeds are available; see the bottom of most pages.