Overview

Simple device drivers serve a single-level directory that can contain only a few files. For example, each UART can be represented by a data file and control file. A more complex device driver such as an Ethernet driver can be represented by a two-level file tree (Figure 2-1) to provide the following:

• Device control and configuration
• User-level protocols
• Diagnostic interfaces

For a local thread that is using it, a kernel device driver is a server in the sense of the Inferno file protocol, Styx, with the messages implemented locally rather than remotely. (See Inferno Communications Protocol, Styx in Chapter 3.)

Advantages of Devices as File System

• Represents dissimilar devices by the same set of files permitting a common set of tools to serve several networks or interfaces
• Avoids byte order problems
• Ensures a uniform representation for devices on the same computer and for devices that are accessed remotely

Pathname Resolution

An Inferno device implements a file tree for client threads. A file name beginning with a pound sign, such as #c, names the root of a file tree implemented by a particular kernel device driver identified by the character after the pound sign. Such names are usually bound to conventional locations in the name space. For example, after

	sys->bind("#c", "/dev", sys->MREPL)

When a system call is passed a file name beginning with #, it looks at the next character, and if that is a valid device character, it performs an attach operation on the corresponding device to get a connection representing the root of that device's file tree. If there are any characters after the device character but before the next slash character ( / ) or end of string, those characters are passed as parameter aname to the attach. (See attach, nop - messages to initiate activity in Chapter 3.)

Each kernel device has a conventional place at which a device is bound to the name space. The device synopses in the following pages include an Inferno shell bind command to put the device in the conventional place. Most of these binds are done automatically by the system when it initializes.

Table 2-1 lists some of the standard Inferno device characters.

Table 2-1 Inferno Devices

/	Root file system, used to construct bootstrap name space
|	Pipe device, used for synchronized inter-process communication
s	Limbo file channel server
F	Key file system, used for storing private keys
M	Mount driver, used to import remote file systems
C	Command execution (not on native)
r	Real-time clock device, controls real-time clock and NVRAM access
I	Internet protocol device, used to implement IP communications
V	Television, provides control for ITV applications
U	Host OS file system (from <inferno_root>)
D	Secure sockets layer, provides encryption support
d	Draw device, implements raster graphics
c	Console device, controls console I/O, keyboard and mouse processing
p	Prog device, provides query and control of status of Inferno threads
t	Serial communications device, used to implement serial communications
l	Ethernet device, used to implement Ethernet communications
E	MPEG device, controls streaming for MPEG devices
A	Digital audio input /output, provides access to stereo audio ports
Note: This table provides a summary of the most common characters. Other standard device characters are being added.

The kernel maintains a table that maps these device characters to device-specific operations for each type of device supported by the kernel. A kernel device driver is a server in the sense of the Styx protocol, with the messages implemented as local rather than remote procedure calls.

Convention for numeric data

See Also

Introduction to Limbo Modules in Chapter 7

Inferno Communications Protocol, Styx in Chapter 3