Lines Matching refs:ioctl

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
138 implemented the \cdrom\ $ioctl()$ calls through their own routines. This
147 software-level, that separates the $ioctl()$ and $open()$ implementation
172         &cdrom_ioctl,           & ioctl \cr
352 \item[1] Open for $ioctl$ commands, as done by audio-CD playing
358 open-for-ioctl call can only fail if there is no hardware.
401 queues for the VFS and a new $ioctl()$ function that can report device
448 operate at 300\,kB/sec you would call the CDROM_SELECT_SPEED $ioctl$
465 This function should implement the old corresponding $ioctl()$. For
500 Some of the \cdrom-$ioctl$s defined in \cdromh\ can be
502 $cdrom_ioctl$ will use those. However, most $ioctl$s deal with
515 An unimplemented ioctl should return $-ENOSYS$, but a harmless request
526 Some $ioctl$s seem to be specific to certain \cdrom\ drives. That is,
528 fact, there are 6 different $ioctl$s for reading data, either in some
532 supported, it should be done through the VFS and not via $ioctl$s. A
542 Because there are so many $ioctl$s that seem to be introduced to
544   actually uses these? I'd be interested!} any `non-standard' $ioctl$s
546 $ioctl$s should be numbered after the device's major number, and not
547 the general \cdrom\ $ioctl$ number, {\tt {0x53}}. Currently the
548 non-supported $ioctl$s are: {\it CDROMREADMODE1, CDROMREADMODE2,
556 Instead of just implementing some $ioctl$ calls, the interface in
593 There is no $ioctl$ to set the mask\dots The reason is that
618 new $ioctl$s implemented in \cdromc, that allow you to control the
636 controlling commands to the device, by the device's $ioctl()$
640 are implemented entirely through $ioctl$s, presumably because the
644 $ioctl$ commands, regardless of the state the drive is in. 
665 $ioctl$ commands, while data use wants to open for correct and
676 that the device is opened just for issuing $ioctl$
711 $ioctl$ informing about media changes.}
714 for $ioctl$ commands only can be easily introduced in the \linux\
719 to old behavior by a call to $ioctl(file_descriptor, CDROM_CLEAR_OPTIONS,
818 \label{cdrom-ioctl}
820 This function handles all the standard $ioctl$ requests for \cdrom\
822 categories: $ioctl$s that can be directly implemented by device
827 \subsubsection{Directly implemented $ioctl$s}
828 \label{ioctl-direct}
830 The following `old' \cdrom-$ioctl$s are implemented by directly
844 \label{ioctl-audio}
846 The following set of $ioctl$s are all implemented through a call to
871 \subsubsection{New $ioctl$s in \cdromc}
873 The following $ioctl$s have been introduced to allow user programs to
874 control the behavior of individual \cdrom\ devices. New $ioctl$
902   $ioctl$ call to $CDROMSUBCHNL$. For juke-boxes, an extra argument
908   This $ioctl$ can provide \emph {some} information about the current
915   This $ioctl$ is useful only in the case that CDs have \emph {only
921   function, the \UCD\ implements this $ioctl$ as follows: If the CD in
931   This $ioctl$ can return:
958 \subsubsection{Device dependent $ioctl$s}
960 Finally, all other $ioctl$s are passed to the function $dev_ioctl()$,
993   part in section~\ref{cdrom-ioctl}, if your code was OK, these are
997   listed in the second part of section~\ref{cdrom-ioctl}). There is no
1004 \item All remaining $ioctl$ cases must be moved to a separate
1005   function, $<device>_ioctl$, the device-dependent $ioctl$s. Note that