> >The real issue here is paradigms. The classical "everything's
> >a file" broke down with the advent of networking, sockets and
> >non-blocking reads.
>
> I think you're going to have to enumerate some of the cases
> where ``everything is a file'' broke down, and then you're
> going to need to enumerate some of the reasons why ``everything
> is a message'' is not exactly the same as ``everything is a
> file'' (aside from ``message'' being spelled differently
> than ``file'', which most people have already figured out.)
A file is a stream of bytes (usually of a known size).
A message can be part of a stream of bytes, a status
report, or something different.
A file is actively read() from, a message can be delivered
very much like a signal. This makes asynchronous I/O more
easy than the file paradigm where async I/O is aided by signals
and other additional cruft.
If the OS only has to tuck a status word onto the message
(or in case of large reads, send a message with a pointer
to a page which has just been mapped into the process'
address space) we again have a consistent interface for
all things in the system.
No longer a difference between files, pipes, network
connections, connectionless network communication and
signals.
One interface to rule them all
One interface to find them
One interface to bind them all
And out of the kernel unwind them :)
Rik -- Open Source: you deserve to be in control of your data.
+-------------------------------------------------------------------+
| Le Reseau netwerksystemen BV: http://www.reseau.nl/ |
| Linux Memory Management site: http://www.linux.eu.org/Linux-MM/ |
| Nederlandse Linux documentatie: http://www.nl.linux.org/ |
+-------------------------------------------------------------------+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/