Lines Matching full:cd
2 A Linux CD-ROM standard
29 This divergence of behavior has been very significant for CD-ROM
32 their drivers totally inconsistent, the writers of Linux CD-ROM
35 maintain uniform behavior across all the Linux CD-ROM drivers.
38 all the different CD-ROM device drivers for Linux. This document also
39 defines the various *ioctl()'s*, and how the low-level CD-ROM device
41 development kernels) several low-level CD-ROM device drivers, including
44 When the CD-ROM was developed, the interface between the CD-ROM drive
46 different CD-ROM interfaces were developed. Some of them had their
55 driver had to be enhanced. History has delivered us CD-ROM support for
56 many of these different interfaces. Nowadays, almost all new CD-ROM
80 I decided to start a discussion on how to make all the Linux CD-ROM
82 the many CD-ROM drivers found in the Linux kernel. Their reactions
83 encouraged me to write the Uniform CD-ROM Driver which this document is
84 intended to describe. The implementation of the Uniform CD-ROM Driver is
86 layer that sits on top of the low-level device drivers for each CD-ROM drive.
88 CD-ROM devices behave **exactly** the same (insofar as the underlying
91 The goal of the Uniform CD-ROM Driver is **not** to alienate driver developers
92 whohave not yet taken steps to support this effort. The goal of Uniform CD-ROM
93 Driver is simply to give people writing application programs for CD-ROM drives
94 **one** Linux CD-ROM interface with consistent behavior for all
95 CD-ROM devices. In addition, this also provides a consistent interface
99 help CD-ROM driver developers adapt their code to use the Uniform CD-ROM
105 more than one CD-ROM drive, possibly of mixed types. It is important
107 cheapest CD-ROM drives was a Philips cm206, a double-speed proprietary
112 16 speed CD-ROM drive, and 24 speed drives are common.
120 implemented the CD-ROM *ioctl()* calls through their own routines. This
126 For this reason, the Uniform CD-ROM Driver was created to enforce consistent
127 CD-ROM drive behavior, and to provide a common set of services to the various
128 low-level CD-ROM device drivers. The Uniform CD-ROM Driver now provides another
133 CD-ROM drivers\' header files to the kernel's cdrom directory. This was
137 CD-ROM drives are specific enough (i. e., different from other
139 of common **CD-ROM device operations**, *<cdrom-device>_dops*.
143 The routines for the Uniform CD-ROM Driver interface level are implemented
144 in the file `cdrom.c`. In this file, the Uniform CD-ROM Driver interfaces
163 Every active CD-ROM device shares this *struct*. The routines
165 place where the behavior of all CD-ROM-devices is defined and
166 standardized. The actual interface to the various types of CD-ROM
167 hardware is still performed by various low-level CD-ROM-device
169 that are common to all CD-ROM (and really, all removable-media
172 Registration of a low-level CD-ROM device driver is now done through
181 CD-ROM device. This structure is conceptually connected to the major
186 This structure contains information about a particular CD-ROM drive,
190 Registering a particular CD-ROM drive with the Uniform CD-ROM Driver
197 CD-ROM device driver. One of the most important entries in this
203 device driver. When `cdrom.c` accesses a CD-ROM device, it does it
205 the capabilities of future CD-ROM drives, so it is expected that this
207 developed. For example, CD-R and CD-R/W drives are beginning to become
236 CD-ROM hardware and/or low-level CD-ROM driver when a CD-ROM drive
237 is registered with the Uniform CD-ROM Driver.
244 CD-ROM drivers don't even look at the major and minor number though,
268 __u8 sanyo_slot : 2; /* Sanyo 3-CD changer support */
292 A few registers contain variables local to the CD-ROM drive. The
293 flags *options* are used to specify how the general CD-ROM routines
308 for read and write, and in case a location on the CD is transferred,
332 - Open for *ioctl* commands, as done by audio-CD playing programs.
400 Some CD-ROM drives are capable of changing their head-speed. There
401 are several reasons for changing the speed of a CD-ROM drive. Badly
402 pressed CD-ROM s may benefit from less-than-maximum head rate. Modern
403 CD-ROM drives can obtain very high head rates (up to *24x* is
412 or 150kB/sec file system data). So to request that a CD-ROM drive
466 Some of the CD-ROM-\ *ioctl()*\ 's defined in `cdrom.h` can be
484 an error is returned by the low-level driver, the Uniform CD-ROM Driver
494 Some *ioctl()'s* seem to be specific to certain CD-ROM drives. That is,
514 the general CD-ROM *ioctl* number, `0x53`. Currently the
526 CD-ROM capabilities
531 of a CD-ROM drive. This can be done by ORing any number of
552 the *cdrom_device_info* variable *mask*. For instance, the SCSI CD-ROM
553 driver has implemented the code for loading and ejecting CD-ROM's, and
555 CD-ROM drive might be a caddy system, which can't load the tray, and
570 A final flag register controls the **behavior** of the CD-ROM
598 The need to know the purpose of opening the CD-ROM device
604 call. The problem with CD-ROM drives, is that they can be used for
606 file systems, CD-ROM's, the other is to play audio CD's. Audio commands
609 nothing wrong with this, but a good control of the `CD player` demands
614 original purpose of CD-ROM s is) we would like to make sure that the
616 scheme, some CD-ROM drivers don't do any integrity checking, resulting
618 attempt for mounting a CD-ROM on an empty drive occurs. This is not a
619 particularly elegant way to find out that there is no CD-ROM inserted;
625 availability of a CD-ROM and its correct type (data), would be
628 These two ways of using a CD-ROM drive, principally for data and
635 parameter (see `open(2)`). For CD-ROM devices, these flags aren't
639 CD-ROM devices: *O_CREAT*, *O_NOCTTY*, *O_TRUNC*, *O_APPEND*, and
640 *O_SYNC* have no meaning to a CD-ROM.
647 inserted some valid data-CD-ROM. Thus, our proposal of the
648 implementation for the *open()* call for CD-ROM s is:
653 on the CD-ROM, such as closing the tray.
672 Incidentally, I think that SUN's approach to mounting CD-ROM s is very
674 newly inserted CD-ROM under `/cdrom/*<volume-name>*`.
677 further and have **every** CD-ROM on the local area network be
679 machine you insert a CD-ROM, it will always appear at the same
687 community. All the CD-player authors will have to be informed, we can
689 has most likely no influence on the behavior of the CD-players on
698 configuration of the behavior of CD-ROM devices (of **any** type)
716 the tray is opened on the last release, i. e., if a CD-ROM is unmounted,
720 maintainers and user program developers) to adopt the new CD-ROM
728 over` the CD-ROM interface to the kernel. The header file belonging
748 Uniform CD-ROM Driver::
774 routines from the CD-ROM interface. This function returns zero upon
805 This function handles all the standard *ioctl* requests for CD-ROM
815 The following `old` CD-ROM *ioctl()*\ 's are implemented by directly
820 Requests the last session on a CD-ROM.
830 Get the Media Catalog Number from a CD.
872 control the behavior of individual CD-ROM devices. New *ioctl*
925 entirely in Uniform CD-ROM Driver.
927 The history of development of the CD's use as a carrier medium for
935 function, the Uniform CD-ROM Driver implements this *ioctl* as
936 follows: If the CD in question has audio tracks on it, and it has
937 absolutely no CD-I, XA, or data tracks on it, it will be reported
940 if the CD in question has any CD-I tracks on it, it will be
941 reported as *CDS_XA_2_2*. Failing that, if the CD in question
943 Finally, if the CD in question has any data tracks on it,
944 it will be reported as a data CD (*CDS_DATA_1*).
990 CD-ROM Driver::
1039 CD-ROM-related code in the 2.1-kernel. Thanks to Scott Snyder and
1041 and IDE-CD drivers and added many ideas for extension of the data
1044 the Linux CD-ROM device driver developers who were kind