Lines Matching refs:of

35 the widest variety of hardware devices. The reasons for this are
39   The large list of hardware devices available for the many platforms
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.
47 The openness of \linux, and the many different types of available
50 all these different devices has also allowed the behavior of each
52 This divergence of behavior has been very significant for \cdrom\
55 their drivers totally inconsistent, the writers of \linux\ \cdrom\
63 drivers should implement them. Currently (as of the \linux\ 2.1.$x$
69 different \cdrom\ interfaces were developed. Some of them had their
73 adapted their drives to one or more of the already existing electrical
75 most of the `NoName' manufacturers). In cases where a new drive really
79 many of these different interfaces. Nowadays, almost all new \cdrom\
86 set of commands and data formats.\footnote{I cannot recollect what
89 features of the software interface had been added to accommodate the
90 capabilities of a particular drive, in an {\fo ad hoc\/} manner. More
91 importantly, it appeared that the behavior of the `standard' commands
92 was different for most of the different drivers: \eg, some drivers
96 ejection. Undoubtedly, the capabilities of the different drives vary,
101 drivers behave more uniformly. I began by contacting the developers of
104 describe. The implementation of the \UCD\ is in the file \cdromc. This
106 of the low-level device drivers for each \cdrom\ drive. By adding this
111 The goal of the \UCD\ is {\em not\/} to alienate driver developers who
112 have not yet taken steps to support this effort. The goal of \UCD\ is
123 the IDE/ATAPI drives and, of course, the SCSI drives, but as prices
124 of hardware drop continuously, it is also likely that people may have
125 more than one \cdrom\ drive, possibly of mixed types. It is important
126 that these drives behave in the same way. In December 1994, one of the
130 standard. At the time of the last update to this document (November
139 led to the danger of different drivers forgetting to do important things
141 importantly, this led to the divergence of behavior, which has already
145 drive behavior, and to provide a common set of services to the various
150 greatest change involved moving the contents of the various low-level
157 of common {\em \cdrom\ device operations}, $<cdrom-device>_dops$.
186 place where the behavior of all \cdrom-devices is defined and
187 standardized. The actual interface to the various types of \cdrom\ 
193 Registration of a low-level \cdrom\ device driver is now done through
197 capabilities of the driver, and the specific drives on which the
203   number of the device (although some drivers may have different
208   connected to the minor number of the device.
217 \cdrom\ device driver. One of the most important entries in this
218 structure is a pointer to the $cdrom_device_ops$ structure of the
222 of pointers to the functions which are implemented in the low-level
225 the capabilities of future \cdrom\ drives, so it is expected that this
252   &int& n_minors;& number of active minor devices \cr
256 When a low-level device driver implements one of these capabilities,
259 NULL instead. The $capability$ flags specify the capabilities of the
262 value indicating the number of minor devices that are supported by
265 $cdrom_device_ops$ because they describe the capability of the {\em
270 $blkdev_fops$ counterparts. This is because very little of the
275 since many of them only support one device.) This will be available
289   & int& mask;& mask of capability: disables them \cr
291   & int& capacity;& number of discs in a jukebox \cr
295   & int& use_count;& number of times device is opened\cr
296   & char& name[20];& name of the device type\cr
299 Using this $struct$, a linked list of the registered minor devices is
301 struct and specifications of properties of the drive are stored in this
304 The $mask$ flags can be used to mask out some of the capabilities listed
306 of the driver. The value $speed$ specifies the maximum head-rate of the
307 drive, measured in units of normal audio speed (176\,kB/sec raw data or
309 number of discs the drive can hold simultaneously, if it is designed
311 because they describe properties of the drive, which don't change after
318 `arbitrary' wishes of the author of the low-level device driver, as is
327 additional bookkeeping. The use count of the device (the number of
333 user-software and low level drivers. This relieves much of the drivers'
337 The implementation of the functions should be as defined in the
342 function call should return only after the command has completed, but of
365 However, strategic actions such as ejection of the tray, or unlocking
373 information on the status of the drive (not the status of the disc,
389 file_operations$. It returns 1 if the medium of the device $cdi\to
401 the desired direction of movement:
412 This function (and no other code) controls locking of the door, if the
413 drive allows this. The value of $lock$ controls the desired locking
425 Some \cdrom\ drives are capable of changing their head-speed. There
426 are several reasons for changing the speed of a \cdrom\ drive. Badly
431 in these circumstances.  Finally, some of these drives can
434 %more than real-time playback of audio might be used for high-speed
435 %copying of audio tracks.
438 played back. The value of $speed$ specifies the head-speed of the
439 drive, measured in units of standard cdrom speed (176\,kB/sec raw data
451 will perform disc selection. It should return the number of the
459 device $cdi\to dev$, the start of the last session of the current disc
462 format will {\em always\/} be of the type $CDROM_LBA$ (linear block
466 (setting the $ms_info\rightarrow addr_format$ field appropriately, of
478 pre-declared memory region of type $struct\ cdrom_mcn$. The MCN is
493 Some of the \cdrom-$ioctl$s defined in \cdromh\ can be
498 the latter is of type $void*{}$, rather than $unsigned\ long\
502 location of $arg$, and reserves stack-memory for the argument. This
503 makes implementation of the $audio_ioctl()$ much simpler than in the
520 they are introduced to service some capabilities of certain drives. In
522 particular kind of format, or audio data. Not many drives support
523 reading audio tracks as data, I believe this is because of protection
524 of copyrights of artists. Moreover, I think that if audio-tracks are
528 (the least common multiple of 512 and 2352), or the drivers should
549 Instead of just implementing some $ioctl$ calls, the interface in
551 of a \cdrom\ drive. This can be done by ORing any number of
553 phase. Currently, the capabilities are any of:
559 CDC_SELECT_SPEED& can select speed, in units of $\sim$150\,kB/s\cr
572 inform \cdromc\ of what the driver can do. If the drive found
581 In the file \cdromc\ you will encounter many constructions of the type
592 A final flag register controls the {\em behavior\/} of the \cdrom\
594 independently of the ideas of the respective author who happened to
608 The initial value of this register is $CDO_AUTO_CLOSE \mathrel|
623 and {\tt sunsite.unc.edu}, allows user level control of these flags. 
625 \newsection{The need to know the purpose of opening the \cdrom\ device}
635 nothing wrong with this, but a good control of the `CD player' demands
637 $ioctl$ commands, regardless of the state the drive is in. 
640 original purpose of \cdrom s is) we would like to make sure that the
643 in a number of i/o errors reported by the VFS to the kernel when an
647 drive for a couple of seconds, after which the system complains it
648 can't read from it. Nowadays we can {\em sense\/} the existence of a
650 fact. An integrity check on opening of the device, that verifies the
651 availability of a \cdrom\ and its correct type (data), would be
654 These two ways of using a \cdrom\ drive, principally for data and
656 behavior of the $open()$ call. Audio use simply wants to open the
660 their {\em purpose\/} of opening the device is, is through the $flags$
670 commands. Strictly, the meaning of $O_NONBLOCK$ is that opening and
673 inserted some valid data-\cdrom.'' Thus, our proposal of the
678 initialization of the transfer. The call may even induce some actions
691 control both the hardware and software of their supported products,
703 differences in behavior of the various drivers, and the need for an
709 even send in our own patches to the programs. The use of $O_NONBLOCK$
710 has most likely no influence on the behavior of the CD-players on
715 \subsection{The preferred strategy of $open()$}
718 configuration of the behavior of \cdrom\ devices (of {\em any\/} type)
720 modes of operation can be set:
728 set, that it contains tracks of type `data mode 1.' Only if all tests
731 set), no actions are taken and a value of 0 will be returned. 
733 mimics the behavior of the current sbpcd-driver. The option flags are
742 \newsection{Description of routines in \cdromc}
747 to \cdromc\ is called \cdromh. Formerly, some of the contents of this
753 The contents of this structure were described in section~\ref{cdrom.c}.
755 of the $struct gendisk$.
793 taking care of all capabilities and options that are set in the
800 This function implements the reverse-logic of $cdrom_open()$, and then
836 The following set of $ioctl$s are all implemented through a call to
838 allocation are performed in $cdrom_ioctl()$, and also sanitization of
841 \item[CDROMSUBCHNL] Get sub-channel data in argument $arg$ of type $struct\
843 \item[CDROMREADTOCHDR] Read Table of Contents header, in $arg$ of type
845 \item[CDROMREADTOCENTRY] Read a Table of Contents entry in $arg$ and
846 specified by $arg$ of type $struct\ cdrom_tocentry *{}$.
848 Frame format, delimited by $arg$ of type $struct\ cdrom_msf *{}$.
850 delimited by $arg$ of type $struct\ \penalty-1000 cdrom_ti *{}$.
851 \item[CDROMVOLCTRL] Set volume specified by $arg$ of type $struct\
853 \item[CDROMVOLREAD] Read volume into by $arg$ of type $struct\
856 \item[CDROMSTOP] Stop playback of audio fragment.
857 \item[CDROMPAUSE] Pause playback of audio fragment.
864 control the behavior of individual \cdrom\ devices. New $ioctl$
872 \item[CDROM_SELECT_SPEED] Select head-rate speed of disc specified as
873   by $arg$ in units of standard cdrom speed (176\,kB/sec raw data or
876   $arg$ is checked against the maximum head rate of the drive found in the
880   maximum number of discs in the juke-box found in the $cdrom_dops$.
888 \item[CDROM_DRIVE_STATUS] Returns the status of the drive by a call to
891   current playing activity of the drive; this can be polled through an
896 \item[CDROM_DISC_STATUS] Returns the type of the disc currently in the
903   The history of development of the CD's use as a carrier medium for
906     one} type of data on them.  While this is often the case, it is
933   For some information concerning frame layout of the various disc
934   types, see a recent version of \cdromh.
936 \item[CDROM_CHANGER_NSLOTS] Returns the number of slots in a
942 \item[CDROM_LOCKDOOR] Locks the door of the drive. $arg == \rm0$
956 \item Make a backup of your current driver. 
957 \item Get hold of the files \cdromc\ and \cdromh, they should be in
960 \item Change the 3rd argument of $register_blkdev$ from
965 \item Copy an example of the device-operations $struct$ to your
974   driver dynamically determines the capabilities of the hardware, this
987   listed in the second part of section~\ref{cdrom-ioctl}). There is no
997 \item Change the prototypes of $<device>_open()$ and
1011 and IDE-CD drivers and added many ideas for extension of the data
1016 of course, I want to thank Linus Torvalds for making this possible in