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
394 queues for the VFS and a new $ioctl()$ function that can report device
441 operate at 300\,kB/sec you would call the CDROM_SELECT_SPEED $ioctl$
458 This function should implement the old corresponding $ioctl()$. For
493 Some of the \cdrom-$ioctl$s defined in \cdromh\ can be
495 $cdrom_ioctl$ will use those. However, most $ioctl$s deal with
508 An unimplemented ioctl should return $-ENOSYS$, but a harmless request
519 Some $ioctl$s seem to be specific to certain \cdrom\ drives. That is,
521 fact, there are 6 different $ioctl$s for reading data, either in some
525 supported, it should be done through the VFS and not via $ioctl$s. A
535 Because there are so many $ioctl$s that seem to be introduced to
537   actually uses these? I'd be interested!} any `non-standard' $ioctl$s
539 $ioctl$s should be numbered after the device's major number, and not
540 the general \cdrom\ $ioctl$ number, {\tt {0x53}}. Currently the
541 non-supported $ioctl$s are: {\it CDROMREADMODE1, CDROMREADMODE2,
549 Instead of just implementing some $ioctl$ calls, the interface in
586 There is no $ioctl$ to set the mask\dots The reason is that
611 new $ioctl$s implemented in \cdromc, that allow you to control the
629 controlling commands to the device, by the device's $ioctl()$
633 are implemented entirely through $ioctl$s, presumably because the
637 $ioctl$ commands, regardless of the state the drive is in. 
658 $ioctl$ commands, while data use wants to open for correct and
669 that the device is opened just for issuing $ioctl$
704 $ioctl$ informing about media changes.}
707 for $ioctl$ commands only can be easily introduced in the \linux\
712 to old behavior by a call to $ioctl(file_descriptor, CDROM_CLEAR_OPTIONS,
808 \label{cdrom-ioctl}
810 This function handles all the standard $ioctl$ requests for \cdrom\
812 categories: $ioctl$s that can be directly implemented by device
817 \subsubsection{Directly implemented $ioctl$s}
818 \label{ioctl-direct}
820 The following `old' \cdrom-$ioctl$s are implemented by directly
834 \label{ioctl-audio}
836 The following set of $ioctl$s are all implemented through a call to
861 \subsubsection{New $ioctl$s in \cdromc}
863 The following $ioctl$s have been introduced to allow user programs to
864 control the behavior of individual \cdrom\ devices. New $ioctl$
892   $ioctl$ call to $CDROMSUBCHNL$. For juke-boxes, an extra argument
898   This $ioctl$ can provide \emph {some} information about the current
905   This $ioctl$ is useful only in the case that CDs have \emph {only
911   function, the \UCD\ implements this $ioctl$ as follows: If the CD in
921   This $ioctl$ can return:
948 \subsubsection{Device dependent $ioctl$s}
950 Finally, all other $ioctl$s are passed to the function $dev_ioctl()$,
983   part in section~\ref{cdrom-ioctl}, if your code was OK, these are
987   listed in the second part of section~\ref{cdrom-ioctl}). There is no
994 \item All remaining $ioctl$ cases must be moved to a separate
995   function, $<device>_ioctl$, the device-dependent $ioctl$s. Note that