Remove whitespace right before punctuation marks in running text.
This commit is contained in:
Giorgos Keramidas
parent
a81654a84a
commit
c4d8816e3d
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=12182
12 changed files with 32 additions and 33 deletions
en_US.ISO8859-1/books
arch-handbook
developers-handbook
driverbasics
isa
jail
kerneldebug
pci
scsi
secure
|
|
@ -49,7 +49,7 @@
|
|||
changes.</para>
|
||||
|
||||
<para>The kld interface is used through the following
|
||||
administrator commands :
|
||||
administrator commands:
|
||||
|
||||
<itemizedlist>
|
||||
<listitem><simpara><command>kldload</command> - loads a new kernel
|
||||
|
|
@ -122,7 +122,7 @@ KMOD=skeleton
|
|||
|
||||
<para>Simply running <command>make</command> with this makefile
|
||||
will create a file <filename>skeleton.ko</filename> that can
|
||||
be loaded into your system by typing :
|
||||
be loaded into your system by typing:
|
||||
<screen>&prompt.root; kldload -v ./skeleton.ko</screen>
|
||||
</para>
|
||||
</sect2>
|
||||
|
|
@ -334,12 +334,12 @@ echo_write(dev_t dev, struct uio *uio, int ioflag)
|
|||
DEV_MODULE(echo,echo_loader,NULL);</programlisting>
|
||||
|
||||
<para>To install this driver you will first need to make a node on
|
||||
your filesystem with a command such as : </para>
|
||||
your filesystem with a command such as:</para>
|
||||
|
||||
<screen>&prompt.root; mknod /dev/echo c 33 0</screen>
|
||||
|
||||
<para>With this driver loaded you should now be able to type
|
||||
something like :</para>
|
||||
something like:</para>
|
||||
|
||||
<screen>&prompt.root; echo -n "Test Data" > /dev/echo
|
||||
&prompt.root; cat /dev/echo
|
||||
|
|
|
|||
|
|
@ -206,7 +206,7 @@
|
|||
|
||||
<listitem><para><function>char
|
||||
*device_get_nameunit(dev)</function> Get the device name
|
||||
including the unit number, such as "xxx0" , "xxx1" and so
|
||||
including the unit number, such as "xxx0", "xxx1" and so
|
||||
on.</para></listitem>
|
||||
|
||||
<listitem><para><function>char
|
||||
|
|
|
|||
|
|
@ -57,7 +57,7 @@
|
|||
<title>Userland code</title>
|
||||
|
||||
<para>The source for the user-land jail is located in
|
||||
<filename>/usr/src/usr.sbin/jail</filename> , consisting of
|
||||
<filename>/usr/src/usr.sbin/jail</filename>, consisting of
|
||||
one file, <filename>jail.c</filename>. The program takes these
|
||||
arguments: the path of the jail, hostname, ip address, and the
|
||||
command to be executed.</para>
|
||||
|
|
|
|||
|
|
@ -234,7 +234,7 @@ DRIVER_MODULE(mypci, pci, mypci_driver, mypci_devclass, 0, 0);</programlisting>
|
|||
the <function>bus_alloc_resource()</function> function.</para>
|
||||
|
||||
<para>For example, a typical driver might have something similar
|
||||
to this in the <function>attach()</function> function. : </para>
|
||||
to this in the <function>attach()</function> function:</para>
|
||||
|
||||
<programlisting> sc->bar0id = 0x10;
|
||||
sc->bar0res = bus_alloc_resource(dev, SYS_RES_MEMORY, &(sc->bar0id),
|
||||
|
|
@ -267,8 +267,7 @@ DRIVER_MODULE(mypci, pci, mypci_driver, mypci_devclass, 0, 0);</programlisting>
|
|||
<para>These handles can then be used to read or write from the
|
||||
device registers with the <function>bus_space_*</function>
|
||||
functions. For example, a driver might contain a shorthand
|
||||
function to read from a board specific register like this :
|
||||
</para>
|
||||
function to read from a board specific register like this:</para>
|
||||
|
||||
<programlisting>uint16_t
|
||||
board_read(struct ni_softc *sc, uint16_t address) {
|
||||
|
|
@ -276,7 +275,7 @@ board_read(struct ni_softc *sc, uint16_t address) {
|
|||
}
|
||||
</programlisting>
|
||||
|
||||
<para>Similarly, one could write to the registers with : </para>
|
||||
<para>Similarly, one could write to the registers with:</para>
|
||||
|
||||
<programlisting>void
|
||||
board_write(struct ni_softc *sc, uint16_t address, uint16_t value) {
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@
|
|||
<para>This document assumes that the reader has a general
|
||||
understanding of device drivers in FreeBSD and of the SCSI
|
||||
protocol. Much of the information in this document was
|
||||
extracted from the drivers :</para>
|
||||
extracted from the drivers:</para>
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
|
|
@ -145,7 +145,7 @@
|
|||
bus? The answer given in the comments to the CAM code is:
|
||||
either way, as the driver's author prefers.</para>
|
||||
|
||||
<para>The arguments are :
|
||||
<para>The arguments are:
|
||||
<itemizedlist>
|
||||
|
||||
<listitem><para><function>action_func</function> - pointer to
|
||||
|
|
@ -1061,7 +1061,7 @@ of the union ccb:</para>
|
|||
|
||||
<listitem><para><emphasis>flags</emphasis> - consists of two
|
||||
parts, binary arguments and identification of
|
||||
sub-operations. The binary arguments are :</para>
|
||||
sub-operations. The binary arguments are:</para>
|
||||
<itemizedlist>
|
||||
<listitem><para><emphasis>CCB_TRANS_DISC_ENB</emphasis> - enable disconnection</para></listitem>
|
||||
<listitem><para><emphasis>CCB_TRANS_TAG_ENB</emphasis> -
|
||||
|
|
@ -1415,7 +1415,7 @@ CCB as done.</para>
|
|||
poll routine. So all it needs to do is to call the interrupt
|
||||
routine (or the other way around, the poll routine may be doing
|
||||
the real action and the interrupt routine would just call the
|
||||
poll routine). Why bother about a separate function then ?
|
||||
poll routine). Why bother about a separate function then?
|
||||
Because of different calling conventions. The
|
||||
<function>xxx_poll</function> routine gets the struct cam_sim
|
||||
pointer as its argument when the PCI interrupt routine by common
|
||||
|
|
@ -1973,7 +1973,7 @@ xxx_timeout(void *arg)
|
|||
<para>When we abort a request all the other disconnected requests
|
||||
to the same target/LUN get aborted too. So there appears a
|
||||
question, should we return them with status CAM_REQ_ABORTED or
|
||||
CAM_CMD_TIMEOUT ? The current drivers use CAM_CMD_TIMEOUT. This
|
||||
CAM_CMD_TIMEOUT? The current drivers use CAM_CMD_TIMEOUT. This
|
||||
seems logical because if one request got timed out then probably
|
||||
something really bad is happening to the device, so if they
|
||||
would not be disturbed they would time out by themselves.</para>
|
||||
|
|
|
|||
|
|
@ -49,7 +49,7 @@
|
|||
changes.</para>
|
||||
|
||||
<para>The kld interface is used through the following
|
||||
administrator commands :
|
||||
administrator commands:
|
||||
|
||||
<itemizedlist>
|
||||
<listitem><simpara><command>kldload</command> - loads a new kernel
|
||||
|
|
@ -122,7 +122,7 @@ KMOD=skeleton
|
|||
|
||||
<para>Simply running <command>make</command> with this makefile
|
||||
will create a file <filename>skeleton.ko</filename> that can
|
||||
be loaded into your system by typing :
|
||||
be loaded into your system by typing:
|
||||
<screen>&prompt.root; kldload -v ./skeleton.ko</screen>
|
||||
</para>
|
||||
</sect2>
|
||||
|
|
@ -334,12 +334,12 @@ echo_write(dev_t dev, struct uio *uio, int ioflag)
|
|||
DEV_MODULE(echo,echo_loader,NULL);</programlisting>
|
||||
|
||||
<para>To install this driver you will first need to make a node on
|
||||
your filesystem with a command such as : </para>
|
||||
your filesystem with a command such as:</para>
|
||||
|
||||
<screen>&prompt.root; mknod /dev/echo c 33 0</screen>
|
||||
|
||||
<para>With this driver loaded you should now be able to type
|
||||
something like :</para>
|
||||
something like:</para>
|
||||
|
||||
<screen>&prompt.root; echo -n "Test Data" > /dev/echo
|
||||
&prompt.root; cat /dev/echo
|
||||
|
|
|
|||
|
|
@ -206,7 +206,7 @@
|
|||
|
||||
<listitem><para><function>char
|
||||
*device_get_nameunit(dev)</function> Get the device name
|
||||
including the unit number, such as "xxx0" , "xxx1" and so
|
||||
including the unit number, such as "xxx0", "xxx1" and so
|
||||
on.</para></listitem>
|
||||
|
||||
<listitem><para><function>char
|
||||
|
|
|
|||
|
|
@ -57,7 +57,7 @@
|
|||
<title>Userland code</title>
|
||||
|
||||
<para>The source for the user-land jail is located in
|
||||
<filename>/usr/src/usr.sbin/jail</filename> , consisting of
|
||||
<filename>/usr/src/usr.sbin/jail</filename>, consisting of
|
||||
one file, <filename>jail.c</filename>. The program takes these
|
||||
arguments: the path of the jail, hostname, ip address, and the
|
||||
command to be executed.</para>
|
||||
|
|
|
|||
|
|
@ -333,7 +333,7 @@
|
|||
<para>The second scenario is to drop to the debugger once the
|
||||
system has booted. There are two simple ways to accomplish
|
||||
this. If you would like to break to the debugger from the
|
||||
command prompt, simply type the command :</para>
|
||||
command prompt, simply type the command:</para>
|
||||
|
||||
<screen>&prompt.root; sysctl debug.enter_debugger=ddb</screen>
|
||||
|
||||
|
|
|
|||
|
|
@ -234,7 +234,7 @@ DRIVER_MODULE(mypci, pci, mypci_driver, mypci_devclass, 0, 0);</programlisting>
|
|||
the <function>bus_alloc_resource()</function> function.</para>
|
||||
|
||||
<para>For example, a typical driver might have something similar
|
||||
to this in the <function>attach()</function> function. : </para>
|
||||
to this in the <function>attach()</function> function:</para>
|
||||
|
||||
<programlisting> sc->bar0id = 0x10;
|
||||
sc->bar0res = bus_alloc_resource(dev, SYS_RES_MEMORY, &(sc->bar0id),
|
||||
|
|
@ -267,8 +267,7 @@ DRIVER_MODULE(mypci, pci, mypci_driver, mypci_devclass, 0, 0);</programlisting>
|
|||
<para>These handles can then be used to read or write from the
|
||||
device registers with the <function>bus_space_*</function>
|
||||
functions. For example, a driver might contain a shorthand
|
||||
function to read from a board specific register like this :
|
||||
</para>
|
||||
function to read from a board specific register like this:</para>
|
||||
|
||||
<programlisting>uint16_t
|
||||
board_read(struct ni_softc *sc, uint16_t address) {
|
||||
|
|
@ -276,7 +275,7 @@ board_read(struct ni_softc *sc, uint16_t address) {
|
|||
}
|
||||
</programlisting>
|
||||
|
||||
<para>Similarly, one could write to the registers with : </para>
|
||||
<para>Similarly, one could write to the registers with:</para>
|
||||
|
||||
<programlisting>void
|
||||
board_write(struct ni_softc *sc, uint16_t address, uint16_t value) {
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@
|
|||
<para>This document assumes that the reader has a general
|
||||
understanding of device drivers in FreeBSD and of the SCSI
|
||||
protocol. Much of the information in this document was
|
||||
extracted from the drivers :</para>
|
||||
extracted from the drivers:</para>
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
|
|
@ -145,7 +145,7 @@
|
|||
bus? The answer given in the comments to the CAM code is:
|
||||
either way, as the driver's author prefers.</para>
|
||||
|
||||
<para>The arguments are :
|
||||
<para>The arguments are:
|
||||
<itemizedlist>
|
||||
|
||||
<listitem><para><function>action_func</function> - pointer to
|
||||
|
|
@ -1061,7 +1061,7 @@ of the union ccb:</para>
|
|||
|
||||
<listitem><para><emphasis>flags</emphasis> - consists of two
|
||||
parts, binary arguments and identification of
|
||||
sub-operations. The binary arguments are :</para>
|
||||
sub-operations. The binary arguments are:</para>
|
||||
<itemizedlist>
|
||||
<listitem><para><emphasis>CCB_TRANS_DISC_ENB</emphasis> - enable disconnection</para></listitem>
|
||||
<listitem><para><emphasis>CCB_TRANS_TAG_ENB</emphasis> -
|
||||
|
|
@ -1415,7 +1415,7 @@ CCB as done.</para>
|
|||
poll routine. So all it needs to do is to call the interrupt
|
||||
routine (or the other way around, the poll routine may be doing
|
||||
the real action and the interrupt routine would just call the
|
||||
poll routine). Why bother about a separate function then ?
|
||||
poll routine). Why bother about a separate function then?
|
||||
Because of different calling conventions. The
|
||||
<function>xxx_poll</function> routine gets the struct cam_sim
|
||||
pointer as its argument when the PCI interrupt routine by common
|
||||
|
|
@ -1973,7 +1973,7 @@ xxx_timeout(void *arg)
|
|||
<para>When we abort a request all the other disconnected requests
|
||||
to the same target/LUN get aborted too. So there appears a
|
||||
question, should we return them with status CAM_REQ_ABORTED or
|
||||
CAM_CMD_TIMEOUT ? The current drivers use CAM_CMD_TIMEOUT. This
|
||||
CAM_CMD_TIMEOUT? The current drivers use CAM_CMD_TIMEOUT. This
|
||||
seems logical because if one request got timed out then probably
|
||||
something really bad is happening to the device, so if they
|
||||
would not be disturbed they would time out by themselves.</para>
|
||||
|
|
|
|||
|
|
@ -403,7 +403,8 @@ int main() {
|
|||
to superuser power for imprisoned processes.</para>
|
||||
|
||||
<para>A superuser process within a jailed environment has the
|
||||
power to : </para>
|
||||
power to:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem><simpara>Manipulate credential with
|
||||
<function>setuid</function>, <function>seteuid</function>,
|
||||
|
|
@ -454,7 +455,7 @@ int main() {
|
|||
|
||||
<para>An application should never assume that anything about the
|
||||
users environment is sane. This includes (but is certainly not
|
||||
limited to) : user input, signals, environment variables,
|
||||
limited to): user input, signals, environment variables,
|
||||
resources, IPC, mmaps, the file system working directory, file
|
||||
descriptors, the # of open files, etc.</para>
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue