Lines Matching +full:drive +full:- +full:open +full:- +full:source

2 \def\version{$Id: cdrom-standard.tex,v 1.9 1997/12/28 15:42:49 david Exp $}
7 \topmargin=-\headheight \advance\topmargin by -\headsep
11 \def\cdrom{{\sc cd-rom}}
12 \def\UCD{{\sc Uniform cd-rom Driver}}
34 \linux\ is probably the Unix-like operating system that supports
40   that \linux\ now supports (\ie, i386-PCs, Sparc Suns, etc.)
42   The open design of the operating system, such that anybody can write a
45   There is plenty of source code around as examples of how to write a driver.
53 devices; the way a particular drive reacts to a `standard' $ioctl()$
62 defines the various $ioctl$s, and how the low-level \cdrom\ device
64 development kernels) several low-level \cdrom\ device drivers, including
67 When the \cdrom\ was developed, the interface between the \cdrom\ drive
75 most of the `NoName' manufacturers). In cases where a new drive really
87 kernel version I looked at, then, presumably 1.2.13 and 1.3.34---the
90 capabilities of a particular drive, in an {\fo ad hoc\/} manner. More
93 close the tray if an $open()$ call occurs when the tray is open, while
106 of the low-level device drivers for each \cdrom\ drive. By adding this
116 between the low-level device driver code and the \linux\ kernel. Care
125 more than one \cdrom\ drive, possibly of mixed types. It is important
127 cheapest \cdrom\ drives was a Philips cm206, a double-speed proprietary
128 drive. In the months that I was busy writing a \linux\ driver for it,
132 16 speed \cdrom\ drive, and 24 speed drives are common.
145 drive behavior, and to provide a common set of services to the various
146 low-level \cdrom\ device drivers. The \UCD\ now provides another
147 software-level, that separates the $ioctl()$ and $open()$ implementation
150 greatest change involved moving the contents of the various low-level
156 block-devices such as floppy or hard disc drives), to define a set
157 of common {\em \cdrom\ device operations}, $<cdrom-device>_dops$.
158 These operations are different from the classical block-device file
159 operations, $<block-device>_fops$.
168         &block_read,            & read---general block-dev read \cr
169         &block_write,           & write---general block-dev write \cr
174         &cdrom_open,            & open \cr
186 place where the behavior of all \cdrom-devices is defined and
188 hardware is still performed by various low-level \cdrom-device
190 that are common to all \cdrom\ (and really, all removable-media
193 Registration of a low-level \cdrom\ device driver is now done through
201   This structure contains information about the low-level driver for a
206   This structure contains information about a particular \cdrom\ drive,
211 Registering a particular \cdrom\ drive with the \UCD\ is done by the
212 low-level device driver though a call to:
216 information needed for the kernel to interface with the low-level
219 low-level driver.
222 of pointers to the functions which are implemented in the low-level
227 developed. For example, CD-R and CD-R/W drives are beginning to become
234   &int& (* open)(struct\ cdrom_device_info *, int)\cr
255 When a low-level device driver implements one of these capabilities,
259 \cdrom\ hardware and/or low-level \cdrom\ driver when a \cdrom\ drive
266 which the major and minor number can be extracted. (Most low-level
271 The drive-specific, minor-like information that is registered with
280   & void *&  handle;& driver-dependent data\cr
287   &unsigned& mc_flags : 2;& media-change buffer flags \cr
293   &__u8& sanyo_slot : 2;& Sanyo 3-CD changer support\cr
307 struct and specifications of properties of the drive are stored in this
311 in $ops\to capability$, if a specific drive doesn't support a feature
312 of the driver. The value $speed$ specifies the maximum head-rate of the
313 drive, measured in units of normal audio speed (176\,kB/sec raw data or
315 because they describe properties of the drive, which don't change after
318 A few registers contain variables local to the \cdrom\ drive. The
322 `arbitrary' wishes of the author of the low-level device driver, as is
325 data that is specific to a minor drive, can be accessed through $handle$,
326 which can point to a data structure specific to the low-level driver.
333 function $cdrom_ioctl()$ will verify the appropriate user-memory regions
335 it will `sanitize' the format by making requests to the low-level
337 user-software and low level drivers. This relieves much of the drivers'
343 $open()$ and $release()$. Other functions may be omitted, their
349 \subsection{$Int\ open(struct\ cdrom_device_info * cdi, int\ purpose)$}
351 $Open()$ should try to open the device for a specific $purpose$, which
354 \item[0] Open for reading data, as done by {\tt {mount()}} (2), or the
356 \item[1] Open for $ioctl$ commands, as done by audio-CD playing
359 Notice that any strategic code (closing tray upon $open()$, etc.)\ is
360 done by the calling routine in \cdromc, so the low-level routine
362 up the disc, etc. % and device-use count
368 Device-specific actions should be taken such as spinning down the device.
374 \label{drive status}
377 information on the status of the drive (not the status of the disc,
378 which may or may not be in the drive). If the drive is not a changer,
395 $disc_nr$ identifies a specific slot in a juke-box, it should be
396 ignored for single-disc drives.  Note that by `re-routing' this
399 changes to software (\eg, an auto-mounting daemon).
408 \item[1] Open tray
410 This function returns 0 upon success, and a non-zero value upon
417 drive allows this. The value of $lock$ controls the desired locking
423 This function returns 0 upon success, and a non-zero value upon
429 Some \cdrom\ drives are capable of changing their head-speed. There
430 are several reasons for changing the speed of a \cdrom\ drive. Badly
431 pressed \cdrom s may benefit from less-than-maximum head rate. Modern
437 %although the audio-low-pass filters probably aren't designed for it,
438 %more than real-time playback of audio might be used for high-speed
442 played back. The value of $speed$ specifies the head-speed of the
443 drive, measured in units of standard cdrom speed (176\,kB/sec raw data
444 or 150\,kB/sec file system data). So to request that a \cdrom\ drive
446 with $speed=2$. The special value `0' means `auto-selection', \ie,
447 maximum data-rate or real-time audio rate. If the drive doesn't have
448 this `auto-selection' capability, the decision should be made on the
454 If the drive can store multiple discs (a juke-box) this function
457 the ide-cd driver supports this functionality.
468 sanitization goes even further: the low-level implementation may
479 that is generally found in the bar-code on the product. Unfortunately,
482 pre-declared memory region of type $struct\ cdrom_mcn$. The MCN is
483 expected as a 13-character string, terminated by a null-character.
487 This call should perform a hard-reset on the drive (although in
488 circumstances that a hard-reset is necessary, a drive may very well not
490 caller only after the drive has finished resetting. If the drive is no
491 longer listening, it may be wise for the underlying low-level cdrom
497 Some of the \cdrom-$ioctl$s defined in \cdromh\ can be
500 audio-control. We have decided to leave these to be accessed through a
506 location of $arg$, and reserves stack-memory for the argument. This
512 An unimplemented ioctl should return $-ENOSYS$, but a harmless request
515 an error is returned by the low-level driver, the \UCD\ tries whenever
518 guarantee a uniform interface to the audio-player software.)
528 of copyrights of artists. Moreover, I think that if audio-tracks are
530 problem here could be the fact that audio-frames are 2352 bytes long,
531 so either the audio-file-system should ask for 75264 bytes at once
541   actually uses these? I'd be interested!} any `non-standard' $ioctl$s
545 non-supported $ioctl$s are: {\it CDROMREADMODE1, CDROMREADMODE2,
547   CDROMPLAY\-BLK and CDROM\-READALL}.
555 of a \cdrom\ drive. This can be done by ORing any number of
556 capability-constants that are defined in \cdromh\ at the registration
561 CDC_OPEN_TRAY& can open tray\cr
564 CDC_SELECT_DISC& drive is juke-box\cr
568 CDC_PLAY_AUDIO& can perform audio-functions (play, pause, etc)\cr
570 CDC_IOCTLS& driver has non-standard ioctls\cr
571 CDC_DRIVE_STATUS& driver implements drive status\cr
576 inform \cdromc\ of what the driver can do. If the drive found
581 \cdrom\ drive might be a caddy system, which can't load the tray, and
582 hence for this drive the $cdrom_device_info$ struct will have set
599 have made the drive's support available to the \linux\ community. The
603 CDO_AUTO_CLOSE& try to close tray upon device $open()$\cr
604 CDO_AUTO_EJECT& try to open tray on last device $close()$\cr
606  purpose for $open()$\cr
641 $ioctl$ commands, regardless of the state the drive is in. 
643 On the other hand, when used as a removable-media disc drive (what the
645 disc drive is ready for operation upon opening the device. In the old
648 attempt for mounting a \cdrom\ on an empty drive occurs. This is not a
650 it more-or-less looks like the old IBM-PC trying to read an empty floppy
651 drive for a couple of seconds, after which the system complains it
653 removable medium in a drive, and we believe we should exploit that
658 These two ways of using a \cdrom\ drive, principally for data and
660 behavior of the $open()$ call. Audio use simply wants to open the
662 $ioctl$ commands, while data use wants to open for correct and
665 parameter (see {\tt {open(2)}}). For \cdrom\ devices, these flags aren't
666 implemented (some drivers implement checking for write-related flags,
677 inserted some valid data-\cdrom.'' Thus, our proposal of the
678 implementation for the $open()$ call for \cdrom s is:
685 successful, unless the whole device doesn't exist. The drive will take
700 volume-daemon automatically mounts a newly inserted \cdrom\ under {\tt
701 {/cdrom/$<volume-name>$/}}. In my opinion they should have pushed this
706 implement such a user-program for \linux, I came across the
712 community. All the CD-player authors will have to be informed, we can
714 has most likely no influence on the behavior of the CD-players on
719 \subsection{The preferred strategy of $open()$}
721 The routines in \cdromc\ are designed in such a way that run-time
730 tray is found to be open, an attempt to close the tray is made. Then,
731 it is verified that a disc is in the drive and, if $CDO_CHECK_TYPE$ is
734 system corruption. If the drive is opened for audio ($O_NONBLOCK$ is
737 mimics the behavior of the current sbpcd-driver. The option flags are
738 ignored, the tray is closed on the first open, if necessary. Similarly,
770 This function returns zero upon success, and non-zero upon
788 the low-level driver, this disconnects the registered device-operation
790 success, and non-zero upon failure.
794 This function is not called directly by the low-level drivers, it is
799 transferred to the device_dependent $open()$ call.
804 This function implements the reverse-logic of $cdrom_open()$, and then
805 calls the device-dependent $release()$ routine. When the use-count has
812 \label{cdrom-ioctl}
818 the remaining ones, that are presumable device-dependent. Generally, a
822 \label{ioctl-direct}
824 The following `old' \cdrom-$ioctl$s are implemented by directly
825 calling device-operations in $cdrom_device_ops$, if implemented and
829 \item[CDROMEJECT] Open tray. 
831 \item[CDROMEJECT_SW] If $arg\not=0$, set behavior to auto-close (close
832 tray on first open) and auto-eject (eject on last release), otherwise
833 set behavior to non-moving on $open()$ and $release()$ calls.
838 \label{ioctl-audio}
845 \item[CDROMSUBCHNL] Get sub-channel data in argument $arg$ of type $struct\
853 \item[CDROMPLAYTRKIND] Play audio fragment in track-index format
854 delimited by $arg$ of type $struct\ \penalty-1000 cdrom_ti *{}$.
876 \item[CDROM_SELECT_SPEED] Select head-rate speed of disc specified as
878   150\,kB/sec file system data). The value 0 means `auto-select', \ie,
880   $arg$ is checked against the maximum head rate of the drive found in the
882 \item[CDROM_SELECT_DISC] Select disc numbered $arg$ from a juke-box.
884   maximum number of discs in the juke-box found in the $cdrom_dops$.
888   a media change once. For juke-boxes, an extra argument $arg$
892 \item[CDROM_DRIVE_STATUS] Returns the status of the drive by a call to
893   $drive_status()$. Return values are defined in section~\ref{drive
895   current playing activity of the drive; this can be polled through an
896   $ioctl$ call to $CDROMSUBCHNL$. For juke-boxes, an extra argument
901   drive.  It should be viewed as a complement to $CDROM_DRIVE_STATUS$.
903   disc that is inserted in the drive.  This functionality used to be
916   question has audio tracks on it, and it has absolutely no CD-I, XA,
920   CD-I tracks on it, it will be reported as $CDS_XA_2_2$.  Failing
941   juke-box. 
942 \item[CDROMRESET] Reset the drive. 
944   drive. Refer to section \ref{capability} for more information on
946 \item[CDROM_LOCKDOOR] Locks the door of the drive. $arg == \rm0$
965 $\&<your-drive>_fops$ to $\&cdrom_fops$. 
967   $$register_cdrom(\&<your-drive>_info);$$
969 \item Copy an example of the device-operations $struct$ to your
970   source, \eg, from {\tt {cm206.c}} $cm206_dops$, and change all
987   part in section~\ref{cdrom-ioctl}, if your code was OK, these are
991   listed in the second part of section~\ref{cdrom-ioctl}). There is no
999   function, $<device>_ioctl$, the device-dependent $ioctl$s. Note that
1013 \cdrom-related code in the 2.1-kernel.  Thanks to Scott Snyder and
1015 and IDE-CD drivers and added many ideas for extension of the data