possible to return the error code to the calling program. (We may decideto sanitize the return value in $cdrom_ioctl()$ though, in order toguarantee a uniform interface to the audio-player software.)\subsection{$Int\ dev_ioctl(struct\ cdrom_device_info * cdi, unsigned\ int\  cmd, unsigned\ long\ arg)$}Some $ioctl$s seem to be specific to certain \cdrom\ drives. That is,they are introduced to service some capabilities of certain drives. Infact, there are 6 different $ioctl$s for reading data, either in someparticular kind of format, or audio data. Not many drives supportreading audio tracks as data, I believe this is because of protectionof copyrights of artists. Moreover, I think that if audio-tracks aresupported, it should be done through the VFS and not via $ioctl$s. Aproblem here could be the fact that audio-frames are 2352 bytes long,so either the audio-file-system should ask for 75264 bytes at once(the least common multiple of 512 and 2352), or the drivers shouldbend their backs to cope with this incoherence (to which I would beopposed).  Furthermore, it is very difficult for the hardware to findthe exact frame boundaries, since there are no synchronization headersin audio frames.  Once these issues are resolved, this code should bestandardized in \cdromc.Because there are so many $ioctl$s that seem to be introduced tosatisfy certain drivers,\footnote{Is there software around that  actually uses these? I'd be interested!} any `non-standard' $ioctl$sare routed through the call $dev_ioctl()$. In principle, `private'$ioctl$s should be numbered after the device's major number, and notthe general \cdrom\ $ioctl$ number, {\tt {0x53}}. Currently thenon-supported $ioctl$s are: {\it CDROMREADMODE1, CDROMREADMODE2,  CDROMREADAUDIO, CDROMREADRAW, CDROMREADCOOKED, CDROMSEEK,  CDROMPLAY\-BLK and CDROM\-READALL}.\subsection{\cdrom\ capabilities}\label{capability}Instead of just implementing some $ioctl$ calls, the interface in\cdromc\ supplies the possibility to indicate the {\em capabilities\/}of a \cdrom\ drive. This can be done by ORing any number ofcapability-constants that are defined in \cdromh\ at the registrationphase. Currently, the capabilities are any of:$$\halign{$#$\ \hfil&$/*$ \rm# $*/$\hfil\crCDC_CLOSE_TRAY& can close tray by software control\crCDC_OPEN_TRAY& can open tray\crCDC_LOCK& can lock and unlock the door\crCDC_SELECT_SPEED& can select speed, in units of $\sim$150\,kB/s\crCDC_SELECT_DISC& drive is juke-box\crCDC_MULTI_SESSION& can read sessions $>\rm1$\crCDC_MCN& can read Media Catalog Number\crCDC_MEDIA_CHANGED& can report if disc has changed\crCDC_PLAY_AUDIO& can perform audio-functions (play, pause, etc)\crCDC_RESET& hard reset device\crCDC_IOCTLS& driver has non-standard ioctls\crCDC_DRIVE_STATUS& driver implements drive status\cr}$$The capability flag is declared $const$, to prevent drivers fromaccidentally tampering with the contents. The capability fags actuallyinform \cdromc\ of what the driver can do. If the drive foundby the driver does not have the capability, is can be masked out bythe $cdrom_device_info$ variable $mask$. For instance, the SCSI \cdrom\driver has implemented the code for loading and ejecting \cdrom's, andhence its corresponding flags in $capability$ will be set. But a SCSI\cdrom\ drive might be a caddy system, which can't load the tray, andhence for this drive the $cdrom_device_info$ struct will have setthe $CDC_CLOSE_TRAY$ bit in $mask$.In the file \cdromc\ you will encounter many constructions of the type$$\itif\ (cdo\rightarrow capability \mathrel\& \mathord{\sim} cdi\rightarrow mask    \mathrel{\&} CDC_<capability>) \ldots$$There is no $ioctl$ to set the mask\dots The reason is thatI think it is better to control the {\em behavior\/} rather than the{\em capabilities}.\subsection{Options}A final flag register controls the {\em behavior\/} of the \cdrom\drives, in order to satisfy different users' wishes, hopefullyindependently of the ideas of the respective author who happened tohave made the drive's support available to the \linux\ community. Thecurrent behavior options are:$$\halign{$#$\ \hfil&$/*$ \rm# $*/$\hfil\crCDO_AUTO_CLOSE& try to close tray upon device $open()$\crCDO_AUTO_EJECT& try to open tray on last device $close()$\crCDO_USE_FFLAGS& use $file_pointer\rightarrow f_flags$ to indicate purpose for $open()$\crCDO_LOCK& try to lock door if device is opened\crCDO_CHECK_TYPE& ensure disc type is data if opened for data\cr}$$The initial value of this register is $CDO_AUTO_CLOSE \mathrel|CDO_USE_FFLAGS \mathrel| CDO_LOCK$, reflecting my own view on userinterface and software standards. Before you protest, there are twonew $ioctl$s implemented in \cdromc, that allow you to control thebehavior by software. These are:$$\halign{$#$\ \hfil&$/*$ \rm# $*/$\hfil\crCDROM_SET_OPTIONS& set options specified in $(int)\ arg$\crCDROM_CLEAR_OPTIONS& clear options specified in $(int)\ arg$\cr}$$One option needs some more explanation: $CDO_USE_FFLAGS$. In the nextnewsection we explain what the need for this option is.A software package {\tt setcd}, available from the Debian distributionand {\tt sunsite.unc.edu}, allows user level control of these flags. \newsection{The need to know the purpose of opening the \cdrom\ device}Traditionally, Unix devices can be used in two different `modes',either by reading/writing to the device file, or by issuingcontrolling commands to the device, by the device's $ioctl()$call. The problem with \cdrom\ drives, is that they can be used fortwo entirely different purposes. One is to mount removablefile systems, \cdrom s, the other is to play audio CD's. Audio commandsare implemented entirely through $ioctl$s, presumably because thefirst implementation (SUN?) has been such. In principle there isnothing wrong with this, but a good control of the `CD player' demandsthat the device can {\em always\/} be opened in order to give the$ioctl$ commands, regardless of the state the drive is in. On the other hand, when used as a removable-media disc drive (what theoriginal purpose of \cdrom s is) we would like to make sure that thedisc drive is ready for operation upon opening the device. In the oldscheme, some \cdrom\ drivers don't do any integrity checking, resultingin a number of i/o errors reported by the VFS to the kernel when anattempt for mounting a \cdrom\ on an empty drive occurs. This is not aparticularly elegant way to find out that there is no \cdrom\ inserted;it more-or-less looks like the old IBM-PC trying to read an empty floppydrive for a couple of seconds, after which the system complains itcan't read from it. Nowadays we can {\em sense\/} the existence of aremovable medium in a drive, and we believe we should exploit thatfact. An integrity check on opening of the device, that verifies theavailability of a \cdrom\ and its correct type (data), would bedesirable.These two ways of using a \cdrom\ drive, principally for data andsecondarily for playing audio discs, have different demands for thebehavior of the $open()$ call. Audio use simply wants to open thedevice in order to get a file handle which is needed for issuing$ioctl$ commands, while data use wants to open for correct andreliable data transfer. The only way user programs can indicate whattheir {\em purpose\/} of opening the device is, is through the $flags$parameter (see {\tt {open(2)}}). For \cdrom\ devices, these flags aren'timplemented (some drivers implement checking for write-related flags,but this is not strictly necessary if the device file has correctpermission flags). Most option flags simply don't make sense to\cdrom\ devices: $O_CREAT$, $O_NOCTTY$, $O_TRUNC$, $O_APPEND$, and$O_SYNC$ have no meaning to a \cdrom. We therefore propose to use the flag $O_NONBLOCK$ to indicatethat the device is opened just for issuing $ioctl$commands. Strictly, the meaning of $O_NONBLOCK$ is that opening andsubsequent calls to the device don't cause the calling process towait. We could interpret this as ``don't wait until someone hasinserted some valid data-\cdrom.'' Thus, our proposal of theimplementation for the $open()$ call for \cdrom s is:\begin{itemize}\item If no other flags are set than $O_RDONLY$, the device is openedfor data transfer, and the return value will be 0 only upon successfulinitialization of the transfer. The call may even induce some actionson the \cdrom, such as closing the tray.  \item If the option flag $O_NONBLOCK$ is set, opening will always besuccessful, unless the whole device doesn't exist. The drive will takeno actions whatsoever. \end{itemize}\subsection{And what about standards?}You might hesitate to accept this proposal as it comes from the\linux\ community, and not from some standardizing institute. Whatabout SUN, SGI, HP and all those other Unix and hardware vendors?Well, these companies are in the lucky position that they generallycontrol both the hardware and software of their supported products,and are large enough to set their own standard. They do not have todeal with a dozen or more different, competing hardwareconfigurations.\footnote{Incidentally, I think that SUN's approach tomounting \cdrom s is very good in origin: under Solaris avolume-daemon automatically mounts a newly inserted \cdrom\ under {\tt{/cdrom/$<volume-name>$/}}. In my opinion they should have pushed thisfurther and have {\em every\/} \cdrom\ on the local area network bemounted at the similar location, \ie, no matter in which particularmachine you insert a \cdrom, it will always appear at the sameposition in the directory tree, on every system. When I wanted toimplement such a user-program for \linux, I came across thedifferences in behavior of the various drivers, and the need for an$ioctl$ informing about media changes.}We believe that using $O_NONBLOCK$ to indicate that a device is being openedfor $ioctl$ commands only can be easily introduced in the \linux\community. All the CD-player authors will have to be informed, we caneven send in our own patches to the programs. The use of $O_NONBLOCK$has most likely no influence on the behavior of the CD-players onother operating systems than \linux. Finally, a user can always revertto old behavior by a call to $ioctl(file_descriptor, CDROM_CLEAR_OPTIONS,CDO_USE_FFLAGS)$. \subsection{The preferred strategy of $open()$}The routines in \cdromc\ are designed in such a way that run-timeconfiguration of the behavior of \cdrom\ devices (of {\em any\/} type)can be carried out, by the $CDROM_SET/CLEAR_OPTIONS$ $ioctls$. Thus, variousmodes of operation can be set:\begin{description}\item[$CDO_AUTO_CLOSE \mathrel| CDO_USE_FFLAGS \mathrel| CDO_LOCK$] Thisis the default setting. (With $CDO_CHECK_TYPE$ it will be better, in thefuture.) If the device is not yet opened by any other process, and ifthe device is being opened for data ($O_NONBLOCK$ is not set) and thetray is found to be open, an attempt to close the tray is made. Then,it is verified that a disc is in the drive and, if $CDO_CHECK_TYPE$ isset, that it contains tracks of type `data mode 1.' Only if all testsare passed is the return value zero. The door is locked to prevent filesystem corruption. If the drive is opened for audio ($O_NONBLOCK$ isset), no actions are taken and a value of 0 will be returned. \item[$CDO_AUTO_CLOSE \mathrel| CDO_AUTO_EJECT \mathrel| CDO_LOCK$] Thismimics the behavior of the current sbpcd-driver. The option flags areignored, the tray is closed on the first open, if necessary. Similarly,the tray is opened on the last release, \ie, if a \cdrom\ is unmounted,it is automatically ejected, such that the user can replace it.\end{description} We hope that these option can convince everybody (both drivermaintainers and user program developers) to adopt the new \cdrom\driver scheme and option flag interpretation.\newsection{Description of routines in \cdromc}Only a few routines in \cdromc\ are exported to the drivers. In thisnew section we will discuss these, as well as the functions that `takeover' the \cdrom\ interface to the kernel. The header file belongingto \cdromc\ is called \cdromh. Formerly, some of the contents of thisfile were placed in the file {\tt {ucdrom.h}}, but this file has now beenmerged back into \cdromh.\subsection{$Struct\ file_operations\ cdrom_fops$}The contents of this structure were described in section~\ref{cdrom.c}.As already stated, this structure should be used to register blockdevices with the kernel:$$register_blkdev(major, <name>, \&cdrom_fops);$$\subsection{$Int\ register_cdrom( struct\ cdrom_device_info\ * cdi)$}This function is used in about the same way one registers $cdrom_fops$with the kernel, the device operations and information structures,as described in section~\ref{cdrom.c}, should be registered with the\UCD:$$register_cdrom(\&<device>_info));$$This function returns zero upon success, and non-zero uponfailure. The structure $<device>_info$ should have a pointer to the