Datastream flow for common print jobs

After a job has been submitted to the spooler for processing and after the qdaemon has accepted the job and determined that the job's turn to be processed has arrived, the backend for the queue is invoked.

The following figure illustrates the process of how piobe uses a shell to construct and manage a pipeline of filters to process the job. The flow of a job through this pipeline of filters, is:

1. backend (piobe) -- (receives arguments through the _argc and _argv subroutines from qdaemon).
2. shell
3. optional filter
4. pioformat
5. device-dependent code
6. pioout
7. device driver

When the device upon which the job is queued becomes available, the qdaemon invokes the backend for the queue. In the base operating system world, the backend is commonly piobe. The qdaemon invokes piobe and passes it arguments in the normal C programming language fashion, using _argc and _argv[].

For example, using the command in step 2 from Spooler data flow (enq command) :

qprt -Pasc -z1 -fp -p12 -s courier -C -N3 /etc/motd

piobe is passed the following arguments:

• argc = 10
• argv[0] = /usr/lib/lpd/piobe
• argv[1] - -f
• argv[2] = p
• argv[3] = -z
• argv[4] = 1
• argv[5] = -p
• argv[6] = 12
• argv[7] = -s
• argv[8] = courier
• argv[9] = /etc/motd

argv[0] is the name of the backend itself, as usual. Note that the -Pasc, which specifies the queue name, was parsed out of the original argument vector, as were the -C and -N3 flags and arguments.

piobe uses the _argv[] values to construct a pipeline of filters that must be executed to process the job as requested. After determining the structure of the pipeline, piobe passes the structure to a shell for realization. If the file parameter in the /etc/qconfig entry for this queue exists, piobe will open the stdout of the last process in the pipeline onto the value specified by the file parameter. The last process in the pipeline is not prevented from re-opening stdout onto some other file or device.

Note the parent-child relationship among these processes, which is not apparent from the figure:

• qdaemon is the parent of piobe.
• piobe is the parent of the shell.
• The shell is the parent of pioout, the last process in the pipeline before the device driver is accessed. pioout is called the Interface Program for Use With the Device Driver or the device driver interface program.
• pioout is the parent of pioformat.
• pioformat dynamically loads and links the device-dependent code at runtime; hence the device-dependent code does not appear as a process in the operating system's process table.
• pioformat is the parent of the optional filter (if it exists), such as the pr filter.

An optional filter, such as pr, can be specified on the command-line (or hardcoded in the colon file) to perform pre-filtering on the job before pioformat processes it.

pioformat is known as a device-independent formatter driver. It will dynamically load, link, and drive various device-dependent formatters to process jobs of a specific data stream type (for example, Postscript, ASCII, GL, or PCL).

Device-dependent code is designed to handle the unique properties of combinations of specific data streams and physical printers. Because combinations of data stream types and printers can be grouped into classes with common attributes, there are currently less than 20 device-dependent modules. These modules are loaded, linked, and driven by pioformat at run time.

pioout is the end of the job-processing pipeline, and is called the device driver interface program. The function of pioout is to take the processed data stream and deliver it to the device for which it was intended, generally a printer. In the typical local print queue environment, it is pioout that has its stdout opened onto the character special file in the /dev directory, as specified by the file parameter in /etc/qconfig.

This is the character special file in the /dev directory that provides access to the device driver for the printer hardware.