Lines Matching refs:em

108 devices behave {\em exactly\/} the same (insofar as the underlying
111 The goal of the \UCD\ is {\em not\/} to alienate driver developers who
114 {\em one\/} \linux\ \cdrom\ interface with consistent behavior for all
131 1997) it is becoming difficult to even {\em find} anything less than a
157 of common {\em \cdrom\ device operations}, $<cdrom-device>_dops$.
189 drivers. These routines simply implement certain {\em capabilities\/}
231 \halign{$#$\ \hfil&$#$\ \hfil&\hbox to 10em{$#$\hss}&
265 $cdrom_device_ops$ because they describe the capability of the {\em
266 driver\/} rather than the {\em drive}. Nomenclature has always been
281 \halign{$#$\ \hfil&$#$\ \hfil&\hbox to 10em{$#$\hss}&
317 flexibility to adapt to the different users' wishes (and {\em not\/} the
338 following sections. Two functions {\em must\/} be implemented, namely
462 format will {\em always\/} be of the type $CDROM_LBA$ (linear block
550 \cdromc\ supplies the possibility to indicate the {\em capabilities\/}
587 I think it is better to control the {\em behavior\/} rather than the
588 {\em capabilities}.
592 A final flag register controls the {\em behavior\/} of the \cdrom\
636 that the device can {\em always\/} be opened in order to give the
648 can't read from it. Nowadays we can {\em sense\/} the existence of a
660 their {\em purpose\/} of opening the device is, is through the $flags$
698 further and have {\em every\/} \cdrom\ on the local area network be
718 configuration of the behavior of \cdrom\ devices (of {\em any\/} type)