Introduction

LINUX is probably the Unix-like operating system that supports the widest variety of hardware devices. The reasons for this are presumably

The vast choice and openness has lead not only to a wide support of hardware devices, but also to a certain divergence in behavior. Especially for CDROM devices, the way a particular drive reacts to a `standard' ioctl () call varies a lot from one brand to another; until today, the LINUX CDROM driver writers kept away from wilderness by a good practice: to evolve a new driver by copying, understanding and changing an existing one.

Since the beginning of the CDROM, many different interfaces developed. Some of them had their own proprietary design (Sony, Mitsumi, Panasonic), other manufacturers adopted an existing electrical interface and changed the functionality (CreativeLabs/SoundBlaster, Teac, Funai) or simply adapted their drives to one or more of the already existing electrical interfaces (Aztech, Sanyo, Funai, Vertos, Longshine, Optics Storage and most of the `NoName' manufacturers). In cases where a new drive really brought his own interface or used his own command set and flow control scheme, either a separate driver had to be written, or an existing driver had to get enhanced.

Nowadays, almost all new CDROM types are either ATAPI/IDE or SCSI; it is very unlikely that any manufacturer still will create a new interface, and new drives for the existing proprietary interfaces are getting rare. But history has delivered us CDROM support for many different interfaces.

Some of the LINUX CDROM driver writers look at the existing standard which is expressed through cdrom.h as to a rather wild set of commands and data formats and feel that any structure is lost, and from this point of view, this documentation shall help to achieve a common programming interface.

Others—mainly those who used the already existing drivers not only as a coding example, but also as a `user interface' reference during their own development—have taken care that cdrom.h reflects a software interface to `user programs' which is unique between all drivers as much as possible; these driver writers will continue to refine the existing cdrom.h where it seems necessary, and they tend to look if any newly requested functionality isn't already there before they are ready to define new structures. The sbpcd driver gives an example that it is possible to let a robot arm play juke box—either with audio or with data CDs—and that it is possible to let the juke box work on even if a disk has fallen upon the floor and the drive door has closed without having a disk inside; without any new software layer or any structures which are not already present in cdrom.h. This `other' group of LINUX CDROM driver writers explicitly does not support the idea to define an additional software layer between driver and user program.

The following text reflects the opinion of the first mentioned LINUX CDROM driver writer group only; the other group (not only the `silent majority') sees this text as a good base for a future documentation of the existing common LINUX CDROM programming interface, as it is stated within cdrom.h. Where cdrom.h needs some external explanation, this text can give it if the reader is aware that—at least at the moment—this text claims to be the proposal of something else than cdrom.h.

Apart from the somewhat unstructured interfacing with software, the actual execution of the commands is different for most of the different drivers: e.g., some drivers close the tray if an open() call occurs while the tray is unloaded, while others do not. Some drivers lock the door upon opening the device, to prevent an incoherent file system, but others don't, to allow software ejection. Undoubtedly, the capabilities of the different drives vary, but even when two drives have the same capability the driver behavior may be different.

Personally, I think that the most important drive interfaces will be the IDE/ATAPI drives and of course the SCSI drives, but as prices of hardware drop continuously, it is not unlikely that people will have more than one CDROM drive, possibly of mixed types. (In December 1994, one of the cheapest CDROM drives was a Philips cm206, a double-speed proprietary drive. In the months that I was busy writing a LINUX driver for it, proprietary drives became old-fashioned and IDE/ATAPI drives became standard. At the time of writing (April 1996) the cheapest double speed drive is IDE and at one fifth of the price of its predecessor. Eight speed drives are available now.)

This document defines (in pre-release versions: proposes) the various ioctls, and the way the drivers should implement this.