Networking with the printer port
(March 1998)

One of the strenghts of Linux is its ability to serve both as engine for powerful number-crunchers and as effective support for minimal computer systems. The PLIP implementation is an outstanding resource in the latter realm, and this article is going to show its internals at the software level. The information herein refers to the 2.0 implementation of the PLIP driver.

by Alessandro Rubini

PLIP means ``Parallel Line Internet Protocol''. It is a protocol to bring IP traffic over a parallel cable; it works with any parallel interface and is able to transfer about 40kB per second. With PLIP you can connect any two computers at virtually no cost. Although nowadays ISA network cards are readily found and installed, you still will enjoy PLIP as soon as you get a laptop, unless you can afford a PCMCIA network card.

PLIP allows to connect your computer to the Internet wherever there is a networked Linux box with a parallel port available, as long as you are root on both systems (only root can load a module or configure an interface).

I find the internal design of PLIP quite interesting at threee levels: it shows how to use simple I/O instructions, it lets you look at how network interfaces fit in the overall kernel, and it shows in practice how kernel software uses the task queues.

Hardware Handling

Before showing any PLIP code, I'd like to describe the workings of the standard parallel port, so you'll be able to understand how the actual data trasfer takes place.

The parallel port is a simple device: its external connector exposes 12 output bits and 5 input bits. Software has direct access to the bits by means of three 8-bit ports: two ports can be written to and the other one can be read from. Moreover, one of the input signals can trigger an interrupt; this ability is enabled by setting a bit in one of the output ports. Figure 1 shows how the three ports are mapped to the 25-pin connector.

Fig. 1
Figure 1: Pinout of the parallel port

The image is available as PostScript here

The ``base_addr'' of a parallel port (the address of its data port) is usually 0x378, 0x278 or 0x3bc. The vast majority of the parallel ports uses 0x378.

Physical access to the ports is achieved by calling two C-language functions, defined in the kernel headers:

#include "<"linux/io.h">"
	unsigned char inb(unsigned short port);
	void outb(unsigned char value, unsigned short port);

The ``b'' in the names means ``byte''. Linux also offers inw (word, 16-bit), inl (long, 32-bit) and their output counterparts, but they are not needed to use the parallel port. The functions just shown are in fact macros, and they expand to a single machine instruction on most Linux plaftorms. Their definition relies on extern inline functions; this means you must turn optimization on when compiling any code using them. The reason behind this is somehow technical, and it is well explained in the gcc man page.

You don't need to be in kernel space to call inb and outb. If you want to access I/O ports from a shell script you can compile inp.c and outp.c and play games with your devices (and even destroy the computer). As you may imagine, only root can access ports.


Based on the description of the parallel port I provided in the previous section, it should be clear that two parties that communicate using PLIP must exchange five bits at a time, at most. The PLIP cable must be specially wired in order to connect five of the outputs of one side to the five iputs at the other side, and vice-versa. The exact pinout of the PLIP cable is described in the source file drivers/net/plip.c and in several places elsewhere, so I won't repeat the information here.

One of the deficiencies of the parallel port is the unavailability of any timing resource in hardware (as opposed to the serial port, which includes its own clock). The communication protocol, therefore, can't exploit any hardware functionality, and any handshake must be performed in software. The chosen protocol uses one of the bits as a strobe signal to assert availability of four data bits; the receiving party must acknowledge reception of such bits by toggling its own strobe line. This approach to data transmission turns out to be very CPU-intensive; the processor must be polling the strobe signal to be able to send out its data, and system performance severely degrades during PLIP data transfers.

The time line of a PLIP transmission is depicted in figure 2, which details the steps involved in the transmission of a single byte of information.

Fig. 2
Figure 2: transmission of a byte of data using PLIP

The image is available as PostScript here

Internet Datagrams

As far as the kernel proper is concerned, the PLIP device is just like any other network device. More specifically, it is like any other ethernet interface even though its name is plipx instead of ethx.

When a datagram must be transmitted through a network interface, it is passed to the transmission function of the device driver. The driver receives a ``socket buffer'' argument (a struct sk_buff) and a pointer to itself (a pointer to struct device).

With PLIP, transmission occurs by encapsulating the IP datagram into an ``hardware header'' for delivery, not unlikely what happens for any other transmission medium. The difference with PLIP is that although it receives a data packet which already includes an Ethernet header, the driver adds its own haeader. A packet encapsulated by PLIP, as it travels over the parallel cable, is made up of the following fields:

Whenever a packet is transmitted, all of the bytes are sent through the cable using the 5-bit protocol described earlier. This is quite straightforward and works flawlessly, unless something goes hairy during transmission.

Asynchronous Operation

The interesting part of a PLIP communication channel is in how asynchronous operations is handled. Transmission and reception of data packets must fit with other system operations, and must be fault-tolerant as much as possible. This involves several kernel resources, and is quite interesting for anyone who's interested in kernel internals.

There are three problems to face in order to achieve reliable PLIP transmission. Outgoing packets must be transmitted asynchronously with the rest of the system (even if transmission is CPU-bound, it should happen outside of the normal computational flow). Incoming packets must too be received asynchronously, and they must be able to notify the PLIP device driver about their arrival. The last problem is fault-tolerance: if one of the parties locks up transmission for any reason, we don't want the peer host to freeze while it waits for a strobe signal.

Asynchronous operation is achieved in PLIP by using the kernel task queues (which have been introduced in the June 1996 issue of Linux Journal). Fault-tolerance and timeouts are implemented using a state-machine implementation, which allows to interleave PLIP transmission/reception with other computational activities without loosing track of the internal status of the transmitter.

Let's imagine to look at a PLIP cable connecting Tanino and Romeo. %% Tanino = Tx, Romeo = Rx. It should be self-explanatory. The following paragraphs explain what happens when Tanino sends a packet to Romeo.

Tanino sends the signal which interrupts Romeo, disables interrupt reporting in its own computer and goes to the transmission loop by registering plip_bh in the immediate task queue and returning. When plip_bh runs, it knows that the interface is sending data and calls plip_send_packet.

Romeo, when interrupted (in plip_interrupt), registers plip_bh in the immediate task queue. The plip_bh function dispatches computation to plip_receive_packet, which disables interrupt reporting in the interface and starts receiving bytes.

Tanino's loop is built on plip_send (which transmits a single byte) while Romeo's loop in build on plip_receive (which receives a single byte). These two functions are ready to detect a timeout condition, and in this case they return the TIMEOUT macro to the calling function, which returns TIMEOUT to plip_bh.

The plip_bh function, when the callee aborts the loop by returning TIMEOUT just registers a function in the timer task queue, so that the loop will be entered again at the next clock tick. If timeout continues after a few clock ticks, transmission or reception of this packet is aborted, and an error is registered in the enet_statistics structure; these erros are shown by the ifconfig command.

If the timeout condition doesn't persist at the next clock tick, data exchange goes on flawlessly. The state machine implemented in the interface is responsible of restarting communication at exactly the place when the timeout occurred.
As you see, the PLIP interface is pretty symmetrical.

Plugging the Driver in Linux

As far as a network driver is concerned, being able to transmit and receive data is not all of its job. The driver needs to interface with the rest of the kernel in order to fit with the rest of the system. The PLIP device driver devotes more ore less one quarter of its source code to interface issues, and I feel it worth introducing here.

Basically, a network interface needs to be able to send and receive packets. Network drivers are organized in a set of ``methods'', like char drivers are (see the KK article published by LJ in April 1996). Sending a packet is easy: one of the methods is concerned with packet transmission, and the driver just implements the right function to transmit data to the network.

Receiving a packet is somehow more hairy, as the packet arrives through an interrupt, and the driver must actively manage received data. Packet reception for any network interface is managed exploting the so-called ``bottom halves'', which deserve an introduction.

In Linux, interrupt handling is split into two halves: the top-half is the hardware interrupt, which is triggered by an hardware event and is executed immediately; and the bottom-half: a software routine that gets scheduled by the kernel when it can run without interfering with normal system operation. Bottom halves are run whenever a process returns from a system call and when ``slow'' interrupt handlers return. When a slow handler runs, all of the processor registers are saved and hardware interrupt are not disabled; therefore, it's safe to run the pending bottom halves when such handlers return. It's interesting to note that new kernels in the 2.1 hierarchy don't differentiate any more between fast and slow interrupt handlers.

A bottom-half handler must be ``marked''; this consists in setting a bit in a bitmask register, so that the kernel will easily check whether any bottom half is pending or not. The immediate task queue, used by the PLIP driver is implemented as a bottom-half: when a task is enqueued, the caller must mark_bh(IMMEDIATE_BH), and the queue will be run as soon as a process is done with a system call, or a slow handler returns.

Back to network interfaces: when a driver receives a network datagram, it must call netif_rx(struct sk_buff *skb), where skb is the buffer hosting the received packet; PLIP calls netif_rx from plip_receive_packet. The netif_rx function enqueues the packet for later processing and calls mark_bh(NET_BH). When bottom halves are run, then, the packet will be processed.

In practice, something more is needed to fit a newtwork interface in the Linux kernel: the module must register its own interface and initialize them. Moreover, an interface must export a few house-keeping functions that the kernel will call. All of this is performed in a few short functions, listed below:

These functions (and hw_start_xmit, the one responsible for actual packet transmission) are all that's needed to run a network interface within Linux. Although I admit the there's more to know in order to write a real driver, I hope the real sources can prove interesting to fill the holes.

More Information

My choice to discuss PLIP is motivated by the easy availability of such network connection, and the ``do it yourself'' approach that might convince someone to build their own infrared ethernet link. If you really are going to peek in the sources to learn how a network interface works, I'd suggest starting with loopback.c, which implements the lo interface, and skeleton.c, which is quite detailed about the problems you'll encounter when building a network driver.

If you are more keen to using PLIP than to write device drivers, you can refer to the PLIP-HOWTO in any LDP mirror, and to /usr/doc/HOWTO in most Linux installations.

Alessandro is always wondering why laptops have a floppy drive instead of a second parallel port. He reads email as, where you can bug him about Linux in general and device drivers in particular.

Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved

Reprinted with permission of Linux Journal