cdrom-standard.tex

Linux内核源代码 为压缩文件 是<<Linux内核>>一书中的源代码

possible to return the error code to the calling program. (We may decide
to sanitize the return value in $cdrom_ioctl()$ though, in order to
guarantee 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. In
fact, there are 6 different $ioctl$s for reading data, either in some
particular kind of format, or audio data. Not many drives support
reading audio tracks as data, I believe this is because of protection
of copyrights of artists. Moreover, I think that if audio-tracks are
supported, it should be done through the VFS and not via $ioctl$s. A
problem 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 should
bend their backs to cope with this incoherence (to which I would be
opposed).  Furthermore, it is very difficult for the hardware to find
the exact frame boundaries, since there are no synchronization headers
in audio frames.  Once these issues are resolved, this code should be
standardized in \cdromc.

Because there are so many $ioctl$s that seem to be introduced to
satisfy certain drivers,\footnote{Is there software around that
  actually uses these? I'd be interested!} any `non-standard' $ioctl$s
are routed through the call $dev_ioctl()$. In principle, `private'
$ioctl$s should be numbered after the device's major number, and not
the general \cdrom\ $ioctl$ number, {\tt {0x53}}. Currently the
non-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 of
capability-constants that are defined in \cdromh\ at the registration
phase. Currently, the capabilities are any of:
$$
\halign{$#$\ \hfil&$/*$ \rm# $*/$\hfil\cr
CDC_CLOSE_TRAY& can close tray by software control\cr
CDC_OPEN_TRAY& can open tray\cr
CDC_LOCK& can lock and unlock the door\cr
CDC_SELECT_SPEED& can select speed, in units of $\sim$150\,kB/s\cr
CDC_SELECT_DISC& drive is juke-box\cr
CDC_MULTI_SESSION& can read sessions $>\rm1$\cr
CDC_MCN& can read Media Catalog Number\cr
CDC_MEDIA_CHANGED& can report if disc has changed\cr
CDC_PLAY_AUDIO& can perform audio-functions (play, pause, etc)\cr
CDC_RESET& hard reset device\cr
CDC_IOCTLS& driver has non-standard ioctls\cr
CDC_DRIVE_STATUS& driver implements drive status\cr
}
$$
The capability flag is declared $const$, to prevent drivers from
accidentally tampering with the contents. The capability fags actually
inform \cdromc\ of what the driver can do. If the drive found
by the driver does not have the capability, is can be masked out by
the $cdrom_device_info$ variable $mask$. For instance, the SCSI \cdrom\
driver has implemented the code for loading and ejecting \cdrom's, and
hence its corresponding flags in $capability$ will be set. But a SCSI
\cdrom\ drive might be a caddy system, which can't load the tray, and
hence for this drive the $cdrom_device_info$ struct will have set
the $CDC_CLOSE_TRAY$ bit in $mask$.

In the file \cdromc\ you will encounter many constructions of the type
$$\it
if\ (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 that
I 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, hopefully
independently of the ideas of the respective author who happened to
have made the drive's support available to the \linux\ community. The
current behavior options are:
$$
\halign{$#$\ \hfil&$/*$ \rm# $*/$\hfil\cr
CDO_AUTO_CLOSE& try to close tray upon device $open()$\cr
CDO_AUTO_EJECT& try to open tray on last device $close()$\cr
CDO_USE_FFLAGS& use $file_pointer\rightarrow f_flags$ to indicate
 purpose for $open()$\cr
CDO_LOCK& try to lock door if device is opened\cr
CDO_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 user
interface and software standards. Before you protest, there are two
new $ioctl$s implemented in \cdromc, that allow you to control the
behavior by software. These are:
$$
\halign{$#$\ \hfil&$/*$ \rm# $*/$\hfil\cr
CDROM_SET_OPTIONS& set options specified in $(int)\ arg$\cr
CDROM_CLEAR_OPTIONS& clear options specified in $(int)\ arg$\cr
}
$$
One option needs some more explanation: $CDO_USE_FFLAGS$. In the next
newsection we explain what the need for this option is.

A software package {\tt setcd}, available from the Debian distribution
and {\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 issuing
controlling commands to the device, by the device's $ioctl()$
call. The problem with \cdrom\ drives, is that they can be used for
two entirely different purposes. One is to mount removable
file systems, \cdrom s, the other is to play audio CD's. Audio commands
are implemented entirely through $ioctl$s, presumably because the
first implementation (SUN?) has been such. In principle there is
nothing wrong with this, but a good control of the `CD player' demands
that 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 the
original purpose of \cdrom s is) we would like to make sure that the
disc drive is ready for operation upon opening the device. In the old
scheme, some \cdrom\ drivers don't do any integrity checking, resulting
in a number of i/o errors reported by the VFS to the kernel when an
attempt for mounting a \cdrom\ on an empty drive occurs. This is not a
particularly 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 floppy
drive for a couple of seconds, after which the system complains it
can't read from it. Nowadays we can {\em sense\/} the existence of a
removable medium in a drive, and we believe we should exploit that
fact. An integrity check on opening of the device, that verifies the
availability of a \cdrom\ and its correct type (data), would be
desirable.

These two ways of using a \cdrom\ drive, principally for data and
secondarily for playing audio discs, have different demands for the
behavior of the $open()$ call. Audio use simply wants to open the
device in order to get a file handle which is needed for issuing
$ioctl$ commands, while data use wants to open for correct and
reliable data transfer. The only way user programs can indicate what
their {\em purpose\/} of opening the device is, is through the $flags$
parameter (see {\tt {open(2)}}). For \cdrom\ devices, these flags aren't
implemented (some drivers implement checking for write-related flags,
but this is not strictly necessary if the device file has correct
permission 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 indicate
that the device is opened just for issuing $ioctl$
commands. Strictly, the meaning of $O_NONBLOCK$ is that opening and
subsequent calls to the device don't cause the calling process to
wait. We could interpret this as ``don't wait until someone has
inserted some valid data-\cdrom.'' Thus, our proposal of the
implementation for the $open()$ call for \cdrom s is:
\begin{itemize}
\item If no other flags are set than $O_RDONLY$, the device is opened
for data transfer, and the return value will be 0 only upon successful
initialization of the transfer. The call may even induce some actions
on the \cdrom, such as closing the tray.  
\item If the option flag $O_NONBLOCK$ is set, opening will always be
successful, unless the whole device doesn't exist. The drive will take
no 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. What
about SUN, SGI, HP and all those other Unix and hardware vendors?
Well, these companies are in the lucky position that they generally
control both the hardware and software of their supported products,
and are large enough to set their own standard. They do not have to
deal with a dozen or more different, competing hardware
configurations.\footnote{Incidentally, I think that SUN's approach to
mounting \cdrom s is very good in origin: under Solaris a
volume-daemon automatically mounts a newly inserted \cdrom\ under {\tt
{/cdrom/$<volume-name>$/}}. In my opinion they should have pushed this
further and have {\em every\/} \cdrom\ on the local area network be
mounted at the similar location, \ie, no matter in which particular
machine you insert a \cdrom, it will always appear at the same
position in the directory tree, on every system. When I wanted to
implement such a user-program for \linux, I came across the
differences 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 opened
for $ioctl$ commands only can be easily introduced in the \linux\
community. All the CD-player authors will have to be informed, we can
even 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 on
other operating systems than \linux. Finally, a user can always revert
to 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-time
configuration of the behavior of \cdrom\ devices (of {\em any\/} type)
can be carried out, by the $CDROM_SET/CLEAR_OPTIONS$ $ioctls$. Thus, various
modes of operation can be set:
\begin{description}
\item[$CDO_AUTO_CLOSE \mathrel| CDO_USE_FFLAGS \mathrel| CDO_LOCK$] This
is the default setting. (With $CDO_CHECK_TYPE$ it will be better, in the
future.) If the device is not yet opened by any other process, and if
the device is being opened for data ($O_NONBLOCK$ is not set) and the
tray 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$ is
set, that it contains tracks of type `data mode 1.' Only if all tests
are passed is the return value zero. The door is locked to prevent file
system corruption. If the drive is opened for audio ($O_NONBLOCK$ is
set), no actions are taken and a value of 0 will be returned. 
\item[$CDO_AUTO_CLOSE \mathrel| CDO_AUTO_EJECT \mathrel| CDO_LOCK$] This
mimics the behavior of the current sbpcd-driver. The option flags are
ignored, 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 driver
maintainers 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 this
new section we will discuss these, as well as the functions that `take
over' the \cdrom\ interface to the kernel. The header file belonging
to \cdromc\ is called \cdromh. Formerly, some of the contents of this
file were placed in the file {\tt {ucdrom.h}}, but this file has now been
merged 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 block
devices 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 upon
failure. The structure $<device>_info$ should have a pointer to the