\section{Einheitlicher Geräte- und Dateizugriff}

Da die Operationen für den Zugriff auf Dateien und Geräte grundsätzlich die
gleichen sind (öffnen, lesen, schreiben, suchen und schließen), liegt
es nahe, Dateien wie Geräte zu behandeln und Geräte wie Dateien.

\subsection{Geräte über Dateien ansprechen}

\subsubsection{Das Dateisystem}

Eine Möglichkeit des Zugriffes -- die gebräuchlichste -- bietet das
Dateisystem. Es benutzt die Schnittstelle des blockorientierten
Gerätes und des zeichenorientierten Gerätes und bietet auf der anderen
Seite eine Schnittstelle für Dateien an. Hier sieht der Benutzer nur
die Dateien.

\subsubsection{Gerätedateien}

Unixsysteme bieten in der Regel einen benutzertransparenten Zugriff
auf Geräte an. Das bedeutet, es existieren im Dateisystem Einträge für
spezielle Gerätedateien, auf die geschrieben werden kann oder von
denen gelesen werden kann wie von normalen Dateien. Dies hat den
Vorteil, dass für Programme, die ihre Dateien wahlweise in Dateien oder
z.B. auf Bandlaufwerke schreiben, keine Rücksicht auf den Speicherort
nehmen müssen.

Implementiert werden diese Einträge über Sockets,
d.h. beim versuchten Zugriff auf solch eine Gerätedatei wird der
Datenstrom weg vom Dateisystem über ein Socket auf das entsprechende
Gerät umgeleitet.

Dies ermöglicht es auch Programmen, die eigentlich zur Operation auf
Dateien bestimmt sind, auf Geräten zu agieren und umgekehrt. So kann
man z.B. mit {\ttfamily cat /dev/rfd0 > /irgendeine/datei} eine
bytegetreue Kopie einer Diskette in eine Datei schreiben.

Auf der anderen Seite ist es z.B. dem Archivierungsprogramm {\ttfamily
  tar} egal, ob es in {\ttfamily /irgendeine/Datei} oder auf das
erste Bandlaufwerk {\ttfamily /dev/rsa0} schreibt.

\subsection{Dateien als Geräte ansprechen}

Unix (und mit zusätzlichen Treibern auch Win32) bietet die
Möglichkeiten Dateien als Geräte anzusprechen. Dies kann z.B. der Fall
sein, wenn man auf die Image-Datei einer CD-Rom zugreifen möchte. Unix
bietet hierfür ein sog. loopback-Device an, einen Treiber, der
zwischen Imagedatei und dem eigentlich zuständigen Dateisystemtreiber
liegt. Mit ihm kann dann auf eine Imagedatei zugegriffen werden, als
wäre sie ein physikalisches Laufwerk.

\subsection{Gerätedateien zu Ende gedacht}

Unix und andere gängige Betriebssysteme haben das
``Everything-Is-A-File''-Paradigma nicht konsequent zu Ende
gedacht. So tauchen Gerätedateien zwar im Namensraum des lokalen
Dateisystems auf, können aber nicht exportiert werden (z.B. per
NFS). Außerdem muß man zum Zugriff auf einen Nameserver diesen meist
über seinen entsprechenden Port und das dazugehörige Protokoll
ansprechen. Man arbeitet beim Programmieren von Netzwerkdiensten also
immer noch sehr rechnernah.

                                % wie man hier gut sehen kann:
                                % Fussnote im laufenden Text eingebaut
                                % 

Diesen Ansatz haben einige Netzwerkbetriebssysteme konsequent
weitergeführt. So ist es bei \emph{Inferno} \cite{Dorw97} möglich, 
Gerätedateien zu exportieren, was dazu führen kann, dass sich ein
Betriebssystem im Netzwerk auflöst. Weiterhin ermöglicht Inferno den
Zugriff auf Netzwerkdienste über Einträge im Namensraum des
Dateisystems\footnote{Diese Einträge können auch bei BSD-basierten
  Unix-Systemen vorhanden sein. Ein sog. Portal Filesystem stellt hierfür
  das Skelett zur Verfügung. Die Gründe dafür, dass dieses Konzept in
  Unix momentan kaum weiterverfolgt wird, dürften in der Dominanz von
  SysVR4 und dem seit 1996 stark geschwundenen Einfluss von BSD
  zu suchen sein.}. 
Analog zum {\ttfamily /dev}-Verzeichnis bei Unix existiert bei
\emph{Inferno} ein {\ttfamily /net}-Verzeichnis, in dem auf die Netzwerkdienste
zugegriffen werden kann. So bezeichnet {\ttfamily /net/dns} den ersten
Nameserver. Schreibt man in diese Gerätedatei nun den Namen eines
aufzulösenden Hosts, so kann man aus ihr die IP-Adresse lesen. Damit
lassen sich auch Netzwerkfunktionen mit den simplen Lese- und
Schreibaufrufen ansprechen.
