Very Computer

Anybody read somewhere or otherwise remember why Linux has no
traditional special files in the /dev directory for network devices
like eth0?  I'm reading up both on device drivers and network stuff
and I'm curious and presuming this is a useful thing to know anyway.

--
Xeno Campanoli (erstwhile Xeno Whitenack, and Rick Burgess)

No real answer for you, but most of the stuff concerning network devices
happens at the kernel level via the TCP/IP stack, where the various devices are
associated with sockets. This "hiding" of network devices may be for security
reasons, or it may just be that there's no real need since there is both a
/dev/tcp and /dev/udp in the /dev directory.

Very informative, thank you!  Now I realize I still have a ton to learn.

Dan

Quote:>Anybody read somewhere or otherwise remember why Linux has no
>traditional special files in the /dev directory for network devices
>like eth0?  I'm reading up both on device drivers and network stuff
>and I'm curious and presuming this is a useful thing to know anyway.

The usual reason for a device special file nodes is so that you can treat
a device as a "file".  This model works for character devices and block
devices, but not for network interfaces.

Network interfaces are, at best, record-based devices.  At worst they are
funky multiplexing things.  There are reasonable semantics for
  cat /dev/zero > /dev/fd0
and
  cat /dev/zero > /dev/ttyS1
but what should happen with?
  cat /dev/zero > /dev/eth0

You might think that
  cat /dev/eth0 > /dev/eth1
could have reasonable semantics, but what do you do if the interface MTUs
are different?  Should you correct the MAC addresses?  Should that impact the
CRC?

This brings up the deeper philisophical/design issue: the concept of the
file system as the single namespace in a Unix system.

Using the file system as the sole namespace, and treating everything as an
unformatted file was a breakthrough idea in 1970.  The developers of Unix
found almost everything could be named and put into a file model.  Life was
simple and good.

In 1980 the introduction of networking into Unix broke that concept, and the
break has never been repaired.  A network connection is easy enough to fit
into the model: the connection is handled with file I/O.  But a network
meant that it was no longer possible to statically name everything.

Dynamically naming things is difficult.  The old, simple model of open() had
to be supplemented by socket()/bind()/accept().  Rather than simple pathname
rules, we now have to deal with address families, protocol families and a
whole bunch of other stuff.  All added in an ad hoc manner.  (IMNSHO, added
badly.  Example: how many programmers know AF_* from PF_*?  Many network
programs would break if AF_xyz != PF_xyz.)

Fitting network interfaces into a clean unified model, just as Unix did with
hardware device and files in 1970, is the next major challenge in OS design.
Read the linux-kernel list. We run into the same problem wearing a different
costume with increasing frequency: hot swapping, CardBus, USB, unexpected
SCSI device mappings, 32 bit device nodes, and DEVFS.  They are all the same
problem: fitting dynamic addressing into a static Unix namespace.

--

Scyld Computing Corporation             http://www.scyld.com
410 Severn Ave. Suite 210               Beowulf Clusters / Linux Installations
Annapolis MD 21403

Was tried with the TLI network interface introduced with System V
release 3  (the AT&T unix release with a network interface but no
network support).  It still survives in Solaris and other SVR4
derivatives, closely related to the STREAMS concept.

Villy