Spelling Fixes:
* loadded -> loaded * useability -> usability * idealogy -> ideology * manpages -> man pages * fucntion -> function * useable -> usable * nowehere -> nowhere * loger -> longer * mechanisim -> mechanism * staticly -> statically * seperatly -> separately * initilized -> initialized * priorites -> priorities * funtions -> functions * predeclard -> predeclared * fuction -> function * signalled -> signaled * keypresses -> key presses * devicere -> device * programing -> programming * begining -> beginning * hardcoding -> hard coding * outputing -> outputting * siginificant -> significant And many other "theword" -> "the word" whitespace fixes in the usb chapter.
This commit is contained in:
Chern Lee
parent
cfb67e5b21
commit
fb68848e50
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=11096
14 changed files with 96 additions and 96 deletions
en_US.ISO8859-1/books
arch-handbook
developers-handbook
driverbasics
introduction
ipv6
isa
pci
sockets
sysinit
usb
x86
|
|
@ -56,7 +56,7 @@
|
|||
module</simpara></listitem>
|
||||
<listitem><simpara><command>kldunload</command> - unloads a kernel
|
||||
module</simpara></listitem>
|
||||
<listitem><simpara><command>kldstat</command> - lists the currently loadded
|
||||
<listitem><simpara><command>kldstat</command> - lists the currently loaded
|
||||
modules</simpara></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
<!--
|
||||
The FreeBSD Documentation Project
|
||||
|
||||
$FreeBSD: doc/en_US.ISO8859-1/books/developers-handbook/isa/chapter.sgml,v 1.1 2001/05/02 01:56:01 murray Exp $
|
||||
$FreeBSD$
|
||||
-->
|
||||
|
||||
<chapter id="isa-driver">
|
||||
|
|
@ -1964,7 +1964,7 @@
|
|||
</programlisting>
|
||||
|
||||
<para>
|
||||
The fucntion <function>xxx_probe_ports()</function> may also
|
||||
The function <function>xxx_probe_ports()</function> may also
|
||||
set the device description depending on the exact model of
|
||||
device it discovers. But if there is only one supported
|
||||
device model this can be as well done in a hardcoded way.
|
||||
|
|
|
|||
|
|
@ -361,7 +361,7 @@ board_write(struct ni_softc *sc, uint16_t address, uint16_t value) {
|
|||
<para>It's very important to deallocate all of the resources
|
||||
that were allocated during <function>attach()</function>.
|
||||
Care must be taken to deallocate the correct stuff even on a
|
||||
failure condition so that the system will remain useable while
|
||||
failure condition so that the system will remain usable while
|
||||
your driver dies.</para>
|
||||
|
||||
</sect2>
|
||||
|
|
|
|||
|
|
@ -1,21 +1,21 @@
|
|||
<!--
|
||||
The FreeBSD Documentation Project
|
||||
|
||||
$FreeBSD: $
|
||||
$FreeBSD$
|
||||
-->
|
||||
|
||||
<chapter id="sysinit">
|
||||
<title>The Sysinit Framework</title>
|
||||
|
||||
<para>Sysinit is the framework for a generic call sort and dispatch
|
||||
mechanisim. FreeBSD currently uses it for the dynamic
|
||||
mechanism. FreeBSD currently uses it for the dynamic
|
||||
initialization of the kernel. Sysinit allows FreeBSD's kernel
|
||||
subsystems to be reordered, and added, removed, and replaced at
|
||||
kernel link time when the kernel or one of its modules is loaded
|
||||
without having to edit a staticly ordered initilization routing
|
||||
without having to edit a statically ordered initialization routing
|
||||
and recompile the kernel. This system also allows kernel modules,
|
||||
currently called <firstterm>KLD's</firstterm>, to be seperatly
|
||||
compiled, linked, and initilized at boot time and loaded even
|
||||
currently called <firstterm>KLD's</firstterm>, to be separately
|
||||
compiled, linked, and initialized at boot time and loaded even
|
||||
later while the system is already running. This is accomplished
|
||||
using the <quote>kernel linker</quote> and <quote>linker
|
||||
sets</quote>.</para>
|
||||
|
|
@ -28,7 +28,7 @@
|
|||
<term>Linker Set</term>
|
||||
<listitem>
|
||||
<para>A linker technique in which the linker gathers
|
||||
staticly declared data throughout a program's source files
|
||||
statically declared data throughout a program's source files
|
||||
into a single contagiously addressable unit of
|
||||
data.</para>
|
||||
</listitem>
|
||||
|
|
@ -47,12 +47,12 @@
|
|||
sets containing each consumer's call order, function, and a
|
||||
pointer to the data to pass to taht function.</para>
|
||||
|
||||
<para>Sysinit uses two priorites when ordering the functions for
|
||||
<para>Sysinit uses two priorities when ordering the functions for
|
||||
execution. The first priority is a subsystem ID giving an
|
||||
overall order Sysinit's dispatch of funtions. Current predeclard
|
||||
overall order Sysinit's dispatch of functions. Current predeclared
|
||||
ID's are in <filename><sys/kernel.h></filename> in the enum
|
||||
list <literal>sysinit_sub_id</literal>. The second priority used
|
||||
is an element order within the subsystem. Current predeclard
|
||||
is an element order within the subsystem. Current predeclared
|
||||
subsystem element orders are in
|
||||
<filename><sys/kernel.h></filename> in the enum list
|
||||
<literal>sysinit_elem_order</literal>.</para>
|
||||
|
|
@ -92,7 +92,7 @@
|
|||
module load. <literal>SYSINIT()</literal> takes a uniquifier
|
||||
that Sysinit uses identify the particular function dispatch
|
||||
data, the subsystem order, the subsystem element order, the
|
||||
function to call, and the data to pass the fuction. All
|
||||
function to call, and the data to pass the function. All
|
||||
functions must take a constant pointer argument.
|
||||
</para>
|
||||
|
||||
|
|
|
|||
|
|
@ -99,7 +99,7 @@
|
|||
specific (classes of) devices. These drivers implement the
|
||||
protocol that is used over the pipes other than the default
|
||||
pipe. They also implement additional functionality to make the
|
||||
device available to other parts of the kernel oruserland. They
|
||||
device available to other parts of the kernel or userland. They
|
||||
use the USB driver interface (USBDI) exposed by the services
|
||||
layer.</para>
|
||||
</sect2>
|
||||
|
|
@ -145,7 +145,7 @@
|
|||
root ports and the changes that have occurred since the last
|
||||
reset of the status change register. Access to these registers
|
||||
is provided through a virtualised hub as suggested in the USB
|
||||
specification [ 2]. Thevirtual hub must comply with the hub
|
||||
specification [ 2]. The virtual hub must comply with the hub
|
||||
device class given in chapter 11 of that specification. It must
|
||||
provide a default pipe through which device requests can be sent
|
||||
to it. It returns the standard andhub class specific set of
|
||||
|
|
@ -157,7 +157,7 @@
|
|||
url="http://www.compaq.com/productinfo/development/openhci.html">Open
|
||||
Host Controller Interface</ulink> (OHCI; Compaq, Microsoft,
|
||||
National Semiconductor). The UHCI specification has been
|
||||
designed to reduce hardware complexity byrequiring the host
|
||||
designed to reduce hardware complexity by requiring the host
|
||||
controller driver to supply a complete schedule of the transfers
|
||||
for each frame. OHCI type controllers are much more independent
|
||||
by providing a more abstract interface doing alot of work
|
||||
|
|
@ -198,7 +198,7 @@
|
|||
will execute all the subqueues scheduled there, followed by
|
||||
all the transfers queued at the bulk QH. To facilitate the
|
||||
handling of finished or failed transfers different types of
|
||||
interrupts are generatedby the hardware at the end of each
|
||||
interrupts are generated by the hardware at the end of each
|
||||
frame. In the last TD for a transfer the Interrupt-On
|
||||
Completion bit is set by the HC driver to flag an interrupt
|
||||
when the transfer has completed. An error interrupt is flagged
|
||||
|
|
@ -258,7 +258,7 @@
|
|||
url="http://www.compaq.com/productinfo/development/openhci.html">
|
||||
OHCI specification</ulink>. Services layer The middle layer
|
||||
provides access to the device in a controlled way and
|
||||
maintains resources inuse by the different drivers and the
|
||||
maintains resources in use by the different drivers and the
|
||||
services layer. The layer takes care of the following
|
||||
aspects:</para>
|
||||
|
||||
|
|
@ -288,7 +288,7 @@
|
|||
interface is a collection of endpoints. For example USB
|
||||
speakers can have an interface for the audio data (Audio
|
||||
Class) and an interface for the knobs, dials and buttons (HID
|
||||
Class). All interfaces in a configuration areactive at the
|
||||
Class). All interfaces in a configuration are active at the
|
||||
same time and can be attached to by different drivers. Each
|
||||
interface can have alternates, providing different quality of
|
||||
service parameters. In for example cameras this is used to
|
||||
|
|
@ -313,7 +313,7 @@
|
|||
in the device by a standard set of descriptors (see section 9.6
|
||||
of the USB specification [ 2]). They can be requested through
|
||||
the Get Descriptor Request. The services layer caches these
|
||||
descriptors to avoid unnecessary transferson the USB
|
||||
descriptors to avoid unnecessary transfers on the USB
|
||||
bus. Access to the descriptors is provided through function
|
||||
calls.</para>
|
||||
|
||||
|
|
@ -336,7 +336,7 @@
|
|||
<listitem><para>Endpoint descriptors: Endpoint address,
|
||||
direction and type, maximum packet size supported and
|
||||
polling frequency if type is interrupt endpoint. There is no
|
||||
descriptor for thedefault endpoint (endpoint 0) and it is
|
||||
descriptor for the default endpoint (endpoint 0) and it is
|
||||
never counted in an interface descriptor.</para></listitem>
|
||||
|
||||
<listitem><para>String descriptors: In the other descriptors
|
||||
|
|
@ -372,7 +372,7 @@
|
|||
the host controller (OHCI) or the HC driver (UHCI) will split
|
||||
the transfer into packets of maximum packet size, with the
|
||||
last packet possibly smaller than the maximum
|
||||
packetsize.</para>
|
||||
packet size.</para>
|
||||
|
||||
<para>Sometimes it is not a problem for a device to return less
|
||||
data than requested. For example abulk-in-transfer to a modem
|
||||
|
|
@ -395,11 +395,11 @@
|
|||
(endpoint 0). The pipe carries the device requests and
|
||||
associated data. The difference between transfers over the
|
||||
default pipe and other pipes is that the protocol for
|
||||
thetransfers is described in the USB specification [ 2]. These
|
||||
the transfers is described in the USB specification [ 2]. These
|
||||
requests are used to reset and configure the device. A basic
|
||||
set of commands that must be supported by each device is
|
||||
provided in chapter 9 of the USB specification [ 2]. The
|
||||
commands supported on this pipe canbe extended by a device
|
||||
commands supported on this pipe can be extended by a device
|
||||
class specification to support additional
|
||||
functionality.</para>
|
||||
|
||||
|
|
@ -409,11 +409,11 @@
|
|||
<listitem><para>Interrupt pipe: The host sends a request for
|
||||
data to the device and if the device has nothing to send, it
|
||||
will NAK the data packet. Interrupt transfers are scheduled
|
||||
at a frequency specifiedwhen creating the
|
||||
at a frequency specified when creating the
|
||||
pipe.</para></listitem>
|
||||
|
||||
<listitem><para>Isochronous pipe: These pipes are intended for
|
||||
isochronous data, for example video oraudio streams, with
|
||||
isochronous data, for example video or audio streams, with
|
||||
fixed latency, but no guaranteed delivery. Some support for
|
||||
pipes of this type is available in the current
|
||||
implementation. Packets in control, bulk and interrupt
|
||||
|
|
@ -426,10 +426,10 @@
|
|||
</itemizedlist>
|
||||
|
||||
<para>The availability of the necessary bandwidth is calculated
|
||||
during the creation of the pipe. Transfersare scheduled within
|
||||
during the creation of the pipe. Transfers are scheduled within
|
||||
frames of 1 millisecond. The bandwidth allocation within a
|
||||
frame is prescribed by the USB specification, section 5.6 [
|
||||
2]. Isochronous and interrupt transfers areallowed to consume
|
||||
2]. Isochronous and interrupt transfers are allowed to consume
|
||||
up to 90% of the bandwidth within a frame. Packets for control
|
||||
and bulk transfers are scheduled after all isochronous and
|
||||
interrupt packets and will consume all the remaining
|
||||
|
|
@ -447,14 +447,14 @@
|
|||
<title>Device probe and attach</title>
|
||||
|
||||
<para>After the notification by the hub that a new device has been
|
||||
connected, the service layer switcheson the port, providing the
|
||||
connected, the service layer switches on the port, providing the
|
||||
device with 100 mA of current. At this point the device is in
|
||||
its default state and listening to device address 0. The
|
||||
services layer will proceed to retrieve the various descriptors
|
||||
through the default pipe. After that it will send a Set Address
|
||||
request to move the device away from the default device address
|
||||
(address 0). Multiple device drivers might be able to support
|
||||
the device. For example a modem driver might beable to support
|
||||
the device. For example a modem driver might be able to support
|
||||
an ISDN TA through the AT compatibility interface. A driver for
|
||||
that specific model of the ISDN adapter might however be able to
|
||||
provide much better support for this device. To support this
|
||||
|
|
@ -462,14 +462,14 @@
|
|||
of support. Support for a specific revision of a product ranks
|
||||
the highest and the generic driver the lowest priority. It might
|
||||
also be that multiple drivers could attach to one device if
|
||||
there are multiple interfaceswithin one configuration. Each
|
||||
there are multiple interfaces within one configuration. Each
|
||||
driver only needs to support a subset of the interfaces.</para>
|
||||
|
||||
<para>The probing for a driver for a newly attached device checks
|
||||
first for device specific drivers. If notfound, the probe code
|
||||
first for device specific drivers. If not found, the probe code
|
||||
iterates over all supported configurations until a driver
|
||||
attaches in a configuration. To support devices with multiple
|
||||
drivers on different interfaces, the probe iteratesover all
|
||||
drivers on different interfaces, the probe iterates over all
|
||||
interfaces in a configuration that have not yet been claimed by
|
||||
a driver. Configurations that exceed the power budget for the
|
||||
hub are ignored. During attach the driver should initialise the
|
||||
|
|
@ -479,14 +479,14 @@
|
|||
should not claim the interrupt pipe at attach time, but
|
||||
should postpone allocating the pipe until the file is opened and
|
||||
the data is actually used. When the file is closed the pipe
|
||||
should be closed again, eventhough the device might still be
|
||||
should be closed again, even though the device might still be
|
||||
attached.</para>
|
||||
|
||||
<sect2>
|
||||
<title>Device disconnect and detach</title>
|
||||
|
||||
<para>A device driver should expect to receive errors during any
|
||||
transaction with the device. The designof USB supports and
|
||||
transaction with the device. The design of USB supports and
|
||||
encourages the disconnection of devices at any point in
|
||||
time. Drivers should make sure that they do the right thing
|
||||
when the device disappears.</para>
|
||||
|
|
@ -498,7 +498,7 @@
|
|||
means of defining an identity for a device have been
|
||||
developed.</para>
|
||||
|
||||
<para>The disconnection of a device is signalled by a hub in the
|
||||
<para>The disconnection of a device is signaled by a hub in the
|
||||
interrupt packet delivered to the hub driver. The status
|
||||
change information indicates which port has seen a connection
|
||||
change. The device detach method for all device drivers for
|
||||
|
|
@ -529,7 +529,7 @@
|
|||
tablets, bar-code readers, buttons, knobs, switches, etc. A
|
||||
third example is the class specification for mass storage
|
||||
devices. For a full list of device classes see the developers
|
||||
sectionon the USB home pages [ 1].</para>
|
||||
section on the USB home pages [ 1].</para>
|
||||
|
||||
<para>For many devices the protocol information has not yet been
|
||||
published however. Information on the protocol being used might
|
||||
|
|
@ -562,7 +562,7 @@
|
|||
built-in legacy mouse port. To avoid having the cost of
|
||||
including the hardware for a USB hub in the device,
|
||||
manufacturers combined the mouse data received from the PS/2 port
|
||||
on the back of the keyboard and the keypresses from the keyboard
|
||||
on the back of the keyboard and the key presses from the keyboard
|
||||
into two separate interfaces in the same configuration. The
|
||||
mouse and keyboard drivers each attach to the appropriate
|
||||
interface and allocate the pipes to the two independent
|
||||
|
|
@ -570,7 +570,7 @@
|
|||
|
||||
<para>Example: Firmware download Many devices that have been
|
||||
developed are based on a general purpose processor with
|
||||
anadditional USB core added to it. Because the development of
|
||||
an additional USB core added to it. Because the development of
|
||||
drivers and firmware for USB devices is still very new, many
|
||||
devices require the downloading of the firmware after they
|
||||
have been connected.</para>
|
||||
|
|
@ -579,7 +579,7 @@
|
|||
identifies itself through a vendor and product Id. The first
|
||||
driver probes and attaches to it and downloads the firmware into
|
||||
it. After that the device soft resets itself and the driver is
|
||||
detached. After a short pause the devicere announces its presence
|
||||
detached. After a short pause the device announces its presence
|
||||
on the bus. The device will have changed its
|
||||
vendor/product/revision Id to reflect the fact that it has been
|
||||
supplied with firmware and as a consequence a second driver will
|
||||
|
|
@ -610,7 +610,7 @@
|
|||
specification specifies exactly what has to happen when and what
|
||||
has to be done in case an error condition is encountered. The
|
||||
biggest challenge when writing drivers for these devices is to
|
||||
fit USB based protocol into theexisting support for mass storage
|
||||
fit USB based protocol into the existing support for mass storage
|
||||
devices. CAM provides hooks to do this in a fairly straight
|
||||
forward way. ATAPI is less simple as historically the IDE
|
||||
interface has never had many different appearances.</para>
|
||||
|
|
|
|||
|
|
@ -56,7 +56,7 @@
|
|||
module</simpara></listitem>
|
||||
<listitem><simpara><command>kldunload</command> - unloads a kernel
|
||||
module</simpara></listitem>
|
||||
<listitem><simpara><command>kldstat</command> - lists the currently loadded
|
||||
<listitem><simpara><command>kldstat</command> - lists the currently loaded
|
||||
modules</simpara></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
<!--
|
||||
The FreeBSD Documentation Project
|
||||
|
||||
$FreeBSD: doc/en_US.ISO8859-1/books/developers-handbook/introduction/chapter.sgml,v 1.3 2001/08/13 06:38:59 jim Exp $
|
||||
$FreeBSD$
|
||||
-->
|
||||
|
||||
<chapter id="introduction">
|
||||
|
|
@ -42,14 +42,14 @@
|
|||
|
||||
<para>To produce the best UNIX-like operating system package
|
||||
possible, with due respect to the original software tools
|
||||
ideology as well as useability, performance and
|
||||
ideology as well as usability, performance and
|
||||
stability.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Architectural Guidelines</title>
|
||||
|
||||
<para>Our idealogy can be described by the following
|
||||
<para>Our ideology can be described by the following
|
||||
guidelines</para>
|
||||
|
||||
<itemizedlist>
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@
|
|||
is not a complete list - this is too hard to maintain...).</para>
|
||||
|
||||
<para>For details please refer to specific chapter in the document,
|
||||
RFCs, manpages, or comments in the source code.</para>
|
||||
RFCs, man pages, or comments in the source code.</para>
|
||||
|
||||
<para>Conformance tests have been performed on the KAME STABLE kit
|
||||
at TAHI project. Results can be viewed at <ulink
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
<!--
|
||||
The FreeBSD Documentation Project
|
||||
|
||||
$FreeBSD: doc/en_US.ISO8859-1/books/developers-handbook/isa/chapter.sgml,v 1.1 2001/05/02 01:56:01 murray Exp $
|
||||
$FreeBSD$
|
||||
-->
|
||||
|
||||
<chapter id="isa-driver">
|
||||
|
|
@ -1964,7 +1964,7 @@
|
|||
</programlisting>
|
||||
|
||||
<para>
|
||||
The fucntion <function>xxx_probe_ports()</function> may also
|
||||
The function <function>xxx_probe_ports()</function> may also
|
||||
set the device description depending on the exact model of
|
||||
device it discovers. But if there is only one supported
|
||||
device model this can be as well done in a hardcoded way.
|
||||
|
|
|
|||
|
|
@ -361,7 +361,7 @@ board_write(struct ni_softc *sc, uint16_t address, uint16_t value) {
|
|||
<para>It's very important to deallocate all of the resources
|
||||
that were allocated during <function>attach()</function>.
|
||||
Care must be taken to deallocate the correct stuff even on a
|
||||
failure condition so that the system will remain useable while
|
||||
failure condition so that the system will remain usable while
|
||||
your driver dies.</para>
|
||||
|
||||
</sect2>
|
||||
|
|
|
|||
|
|
@ -1654,7 +1654,7 @@ struct servent * getservbyname(const char *name, const char *proto);
|
|||
<para>You usually do know the port. But if you are developing a
|
||||
new protocol, you may be testing it on an unofficial
|
||||
port. Some day, you will register the protocol and its port
|
||||
(if nowehere else, at least in your
|
||||
(if nowhere else, at least in your
|
||||
<filename>/etc/services</filename>, which is where
|
||||
<function>getservbyname</function> looks). Instead of
|
||||
returning an error in the above code, you just use the
|
||||
|
|
@ -1756,7 +1756,7 @@ struct servent * getservbyname(const char *name, const char *proto);
|
|||
process</emphasis> cannot simply stop and wait. That would
|
||||
defeat the whole purpose of creating additional processes. But
|
||||
if it never does <function>wait</function>, its children will
|
||||
become <emphasis>zombies</emphasis>—no loger functional
|
||||
become <emphasis>zombies</emphasis>—no longer functional
|
||||
but still roaming around.</para>
|
||||
|
||||
<para>For that reason, the <emphasis>daemon process</emphasis>
|
||||
|
|
|
|||
|
|
@ -1,21 +1,21 @@
|
|||
<!--
|
||||
The FreeBSD Documentation Project
|
||||
|
||||
$FreeBSD: $
|
||||
$FreeBSD$
|
||||
-->
|
||||
|
||||
<chapter id="sysinit">
|
||||
<title>The Sysinit Framework</title>
|
||||
|
||||
<para>Sysinit is the framework for a generic call sort and dispatch
|
||||
mechanisim. FreeBSD currently uses it for the dynamic
|
||||
mechanism. FreeBSD currently uses it for the dynamic
|
||||
initialization of the kernel. Sysinit allows FreeBSD's kernel
|
||||
subsystems to be reordered, and added, removed, and replaced at
|
||||
kernel link time when the kernel or one of its modules is loaded
|
||||
without having to edit a staticly ordered initilization routing
|
||||
without having to edit a statically ordered initialization routing
|
||||
and recompile the kernel. This system also allows kernel modules,
|
||||
currently called <firstterm>KLD's</firstterm>, to be seperatly
|
||||
compiled, linked, and initilized at boot time and loaded even
|
||||
currently called <firstterm>KLD's</firstterm>, to be separately
|
||||
compiled, linked, and initialized at boot time and loaded even
|
||||
later while the system is already running. This is accomplished
|
||||
using the <quote>kernel linker</quote> and <quote>linker
|
||||
sets</quote>.</para>
|
||||
|
|
@ -28,7 +28,7 @@
|
|||
<term>Linker Set</term>
|
||||
<listitem>
|
||||
<para>A linker technique in which the linker gathers
|
||||
staticly declared data throughout a program's source files
|
||||
statically declared data throughout a program's source files
|
||||
into a single contagiously addressable unit of
|
||||
data.</para>
|
||||
</listitem>
|
||||
|
|
@ -47,12 +47,12 @@
|
|||
sets containing each consumer's call order, function, and a
|
||||
pointer to the data to pass to taht function.</para>
|
||||
|
||||
<para>Sysinit uses two priorites when ordering the functions for
|
||||
<para>Sysinit uses two priorities when ordering the functions for
|
||||
execution. The first priority is a subsystem ID giving an
|
||||
overall order Sysinit's dispatch of funtions. Current predeclard
|
||||
overall order Sysinit's dispatch of functions. Current predeclared
|
||||
ID's are in <filename><sys/kernel.h></filename> in the enum
|
||||
list <literal>sysinit_sub_id</literal>. The second priority used
|
||||
is an element order within the subsystem. Current predeclard
|
||||
is an element order within the subsystem. Current predeclared
|
||||
subsystem element orders are in
|
||||
<filename><sys/kernel.h></filename> in the enum list
|
||||
<literal>sysinit_elem_order</literal>.</para>
|
||||
|
|
@ -92,7 +92,7 @@
|
|||
module load. <literal>SYSINIT()</literal> takes a uniquifier
|
||||
that Sysinit uses identify the particular function dispatch
|
||||
data, the subsystem order, the subsystem element order, the
|
||||
function to call, and the data to pass the fuction. All
|
||||
function to call, and the data to pass the function. All
|
||||
functions must take a constant pointer argument.
|
||||
</para>
|
||||
|
||||
|
|
|
|||
|
|
@ -99,7 +99,7 @@
|
|||
specific (classes of) devices. These drivers implement the
|
||||
protocol that is used over the pipes other than the default
|
||||
pipe. They also implement additional functionality to make the
|
||||
device available to other parts of the kernel oruserland. They
|
||||
device available to other parts of the kernel or userland. They
|
||||
use the USB driver interface (USBDI) exposed by the services
|
||||
layer.</para>
|
||||
</sect2>
|
||||
|
|
@ -145,7 +145,7 @@
|
|||
root ports and the changes that have occurred since the last
|
||||
reset of the status change register. Access to these registers
|
||||
is provided through a virtualised hub as suggested in the USB
|
||||
specification [ 2]. Thevirtual hub must comply with the hub
|
||||
specification [ 2]. The virtual hub must comply with the hub
|
||||
device class given in chapter 11 of that specification. It must
|
||||
provide a default pipe through which device requests can be sent
|
||||
to it. It returns the standard andhub class specific set of
|
||||
|
|
@ -157,7 +157,7 @@
|
|||
url="http://www.compaq.com/productinfo/development/openhci.html">Open
|
||||
Host Controller Interface</ulink> (OHCI; Compaq, Microsoft,
|
||||
National Semiconductor). The UHCI specification has been
|
||||
designed to reduce hardware complexity byrequiring the host
|
||||
designed to reduce hardware complexity by requiring the host
|
||||
controller driver to supply a complete schedule of the transfers
|
||||
for each frame. OHCI type controllers are much more independent
|
||||
by providing a more abstract interface doing alot of work
|
||||
|
|
@ -198,7 +198,7 @@
|
|||
will execute all the subqueues scheduled there, followed by
|
||||
all the transfers queued at the bulk QH. To facilitate the
|
||||
handling of finished or failed transfers different types of
|
||||
interrupts are generatedby the hardware at the end of each
|
||||
interrupts are generated by the hardware at the end of each
|
||||
frame. In the last TD for a transfer the Interrupt-On
|
||||
Completion bit is set by the HC driver to flag an interrupt
|
||||
when the transfer has completed. An error interrupt is flagged
|
||||
|
|
@ -258,7 +258,7 @@
|
|||
url="http://www.compaq.com/productinfo/development/openhci.html">
|
||||
OHCI specification</ulink>. Services layer The middle layer
|
||||
provides access to the device in a controlled way and
|
||||
maintains resources inuse by the different drivers and the
|
||||
maintains resources in use by the different drivers and the
|
||||
services layer. The layer takes care of the following
|
||||
aspects:</para>
|
||||
|
||||
|
|
@ -288,7 +288,7 @@
|
|||
interface is a collection of endpoints. For example USB
|
||||
speakers can have an interface for the audio data (Audio
|
||||
Class) and an interface for the knobs, dials and buttons (HID
|
||||
Class). All interfaces in a configuration areactive at the
|
||||
Class). All interfaces in a configuration are active at the
|
||||
same time and can be attached to by different drivers. Each
|
||||
interface can have alternates, providing different quality of
|
||||
service parameters. In for example cameras this is used to
|
||||
|
|
@ -313,7 +313,7 @@
|
|||
in the device by a standard set of descriptors (see section 9.6
|
||||
of the USB specification [ 2]). They can be requested through
|
||||
the Get Descriptor Request. The services layer caches these
|
||||
descriptors to avoid unnecessary transferson the USB
|
||||
descriptors to avoid unnecessary transfers on the USB
|
||||
bus. Access to the descriptors is provided through function
|
||||
calls.</para>
|
||||
|
||||
|
|
@ -336,7 +336,7 @@
|
|||
<listitem><para>Endpoint descriptors: Endpoint address,
|
||||
direction and type, maximum packet size supported and
|
||||
polling frequency if type is interrupt endpoint. There is no
|
||||
descriptor for thedefault endpoint (endpoint 0) and it is
|
||||
descriptor for the default endpoint (endpoint 0) and it is
|
||||
never counted in an interface descriptor.</para></listitem>
|
||||
|
||||
<listitem><para>String descriptors: In the other descriptors
|
||||
|
|
@ -372,7 +372,7 @@
|
|||
the host controller (OHCI) or the HC driver (UHCI) will split
|
||||
the transfer into packets of maximum packet size, with the
|
||||
last packet possibly smaller than the maximum
|
||||
packetsize.</para>
|
||||
packet size.</para>
|
||||
|
||||
<para>Sometimes it is not a problem for a device to return less
|
||||
data than requested. For example abulk-in-transfer to a modem
|
||||
|
|
@ -395,11 +395,11 @@
|
|||
(endpoint 0). The pipe carries the device requests and
|
||||
associated data. The difference between transfers over the
|
||||
default pipe and other pipes is that the protocol for
|
||||
thetransfers is described in the USB specification [ 2]. These
|
||||
the transfers is described in the USB specification [ 2]. These
|
||||
requests are used to reset and configure the device. A basic
|
||||
set of commands that must be supported by each device is
|
||||
provided in chapter 9 of the USB specification [ 2]. The
|
||||
commands supported on this pipe canbe extended by a device
|
||||
commands supported on this pipe can be extended by a device
|
||||
class specification to support additional
|
||||
functionality.</para>
|
||||
|
||||
|
|
@ -409,11 +409,11 @@
|
|||
<listitem><para>Interrupt pipe: The host sends a request for
|
||||
data to the device and if the device has nothing to send, it
|
||||
will NAK the data packet. Interrupt transfers are scheduled
|
||||
at a frequency specifiedwhen creating the
|
||||
at a frequency specified when creating the
|
||||
pipe.</para></listitem>
|
||||
|
||||
<listitem><para>Isochronous pipe: These pipes are intended for
|
||||
isochronous data, for example video oraudio streams, with
|
||||
isochronous data, for example video or audio streams, with
|
||||
fixed latency, but no guaranteed delivery. Some support for
|
||||
pipes of this type is available in the current
|
||||
implementation. Packets in control, bulk and interrupt
|
||||
|
|
@ -426,10 +426,10 @@
|
|||
</itemizedlist>
|
||||
|
||||
<para>The availability of the necessary bandwidth is calculated
|
||||
during the creation of the pipe. Transfersare scheduled within
|
||||
during the creation of the pipe. Transfers are scheduled within
|
||||
frames of 1 millisecond. The bandwidth allocation within a
|
||||
frame is prescribed by the USB specification, section 5.6 [
|
||||
2]. Isochronous and interrupt transfers areallowed to consume
|
||||
2]. Isochronous and interrupt transfers are allowed to consume
|
||||
up to 90% of the bandwidth within a frame. Packets for control
|
||||
and bulk transfers are scheduled after all isochronous and
|
||||
interrupt packets and will consume all the remaining
|
||||
|
|
@ -447,14 +447,14 @@
|
|||
<title>Device probe and attach</title>
|
||||
|
||||
<para>After the notification by the hub that a new device has been
|
||||
connected, the service layer switcheson the port, providing the
|
||||
connected, the service layer switches on the port, providing the
|
||||
device with 100 mA of current. At this point the device is in
|
||||
its default state and listening to device address 0. The
|
||||
services layer will proceed to retrieve the various descriptors
|
||||
through the default pipe. After that it will send a Set Address
|
||||
request to move the device away from the default device address
|
||||
(address 0). Multiple device drivers might be able to support
|
||||
the device. For example a modem driver might beable to support
|
||||
the device. For example a modem driver might be able to support
|
||||
an ISDN TA through the AT compatibility interface. A driver for
|
||||
that specific model of the ISDN adapter might however be able to
|
||||
provide much better support for this device. To support this
|
||||
|
|
@ -462,14 +462,14 @@
|
|||
of support. Support for a specific revision of a product ranks
|
||||
the highest and the generic driver the lowest priority. It might
|
||||
also be that multiple drivers could attach to one device if
|
||||
there are multiple interfaceswithin one configuration. Each
|
||||
there are multiple interfaces within one configuration. Each
|
||||
driver only needs to support a subset of the interfaces.</para>
|
||||
|
||||
<para>The probing for a driver for a newly attached device checks
|
||||
first for device specific drivers. If notfound, the probe code
|
||||
first for device specific drivers. If not found, the probe code
|
||||
iterates over all supported configurations until a driver
|
||||
attaches in a configuration. To support devices with multiple
|
||||
drivers on different interfaces, the probe iteratesover all
|
||||
drivers on different interfaces, the probe iterates over all
|
||||
interfaces in a configuration that have not yet been claimed by
|
||||
a driver. Configurations that exceed the power budget for the
|
||||
hub are ignored. During attach the driver should initialise the
|
||||
|
|
@ -479,14 +479,14 @@
|
|||
should not claim the interrupt pipe at attach time, but
|
||||
should postpone allocating the pipe until the file is opened and
|
||||
the data is actually used. When the file is closed the pipe
|
||||
should be closed again, eventhough the device might still be
|
||||
should be closed again, even though the device might still be
|
||||
attached.</para>
|
||||
|
||||
<sect2>
|
||||
<title>Device disconnect and detach</title>
|
||||
|
||||
<para>A device driver should expect to receive errors during any
|
||||
transaction with the device. The designof USB supports and
|
||||
transaction with the device. The design of USB supports and
|
||||
encourages the disconnection of devices at any point in
|
||||
time. Drivers should make sure that they do the right thing
|
||||
when the device disappears.</para>
|
||||
|
|
@ -498,7 +498,7 @@
|
|||
means of defining an identity for a device have been
|
||||
developed.</para>
|
||||
|
||||
<para>The disconnection of a device is signalled by a hub in the
|
||||
<para>The disconnection of a device is signaled by a hub in the
|
||||
interrupt packet delivered to the hub driver. The status
|
||||
change information indicates which port has seen a connection
|
||||
change. The device detach method for all device drivers for
|
||||
|
|
@ -529,7 +529,7 @@
|
|||
tablets, bar-code readers, buttons, knobs, switches, etc. A
|
||||
third example is the class specification for mass storage
|
||||
devices. For a full list of device classes see the developers
|
||||
sectionon the USB home pages [ 1].</para>
|
||||
section on the USB home pages [ 1].</para>
|
||||
|
||||
<para>For many devices the protocol information has not yet been
|
||||
published however. Information on the protocol being used might
|
||||
|
|
@ -562,7 +562,7 @@
|
|||
built-in legacy mouse port. To avoid having the cost of
|
||||
including the hardware for a USB hub in the device,
|
||||
manufacturers combined the mouse data received from the PS/2 port
|
||||
on the back of the keyboard and the keypresses from the keyboard
|
||||
on the back of the keyboard and the key presses from the keyboard
|
||||
into two separate interfaces in the same configuration. The
|
||||
mouse and keyboard drivers each attach to the appropriate
|
||||
interface and allocate the pipes to the two independent
|
||||
|
|
@ -570,7 +570,7 @@
|
|||
|
||||
<para>Example: Firmware download Many devices that have been
|
||||
developed are based on a general purpose processor with
|
||||
anadditional USB core added to it. Because the development of
|
||||
an additional USB core added to it. Because the development of
|
||||
drivers and firmware for USB devices is still very new, many
|
||||
devices require the downloading of the firmware after they
|
||||
have been connected.</para>
|
||||
|
|
@ -579,7 +579,7 @@
|
|||
identifies itself through a vendor and product Id. The first
|
||||
driver probes and attaches to it and downloads the firmware into
|
||||
it. After that the device soft resets itself and the driver is
|
||||
detached. After a short pause the devicere announces its presence
|
||||
detached. After a short pause the device announces its presence
|
||||
on the bus. The device will have changed its
|
||||
vendor/product/revision Id to reflect the fact that it has been
|
||||
supplied with firmware and as a consequence a second driver will
|
||||
|
|
@ -610,7 +610,7 @@
|
|||
specification specifies exactly what has to happen when and what
|
||||
has to be done in case an error condition is encountered. The
|
||||
biggest challenge when writing drivers for these devices is to
|
||||
fit USB based protocol into theexisting support for mass storage
|
||||
fit USB based protocol into the existing support for mass storage
|
||||
devices. CAM provides hooks to do this in a fairly straight
|
||||
forward way. ATAPI is less simple as historically the IDE
|
||||
interface has never had many different appearances.</para>
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@
|
|||
author to assign us the copyright. For now, it is valuable
|
||||
content so it should stay.
|
||||
|
||||
$FreeBSD: doc/en_US.ISO8859-1/books/developers-handbook/x86/chapter.sgml,v 1.4 2001/06/23 06:56:59 dd Exp $
|
||||
$FreeBSD$
|
||||
-->
|
||||
|
||||
<chapter id="x86">
|
||||
|
|
@ -33,7 +33,7 @@ This chapter was written by G. Adam Stanislav.
|
|||
<title>Synopsis</title>
|
||||
|
||||
<para>
|
||||
Assembly language programing under Unix is highly undocumented. It
|
||||
Assembly language programming under Unix is highly undocumented. It
|
||||
is generally assumed that no one would ever want to use it because
|
||||
various Unix systems run on different microprocessors, so everything
|
||||
should be written in C for portability.
|
||||
|
|
@ -1060,7 +1060,7 @@ a "new line" convention, which is <constant>0A</constant> in hexadecimal.
|
|||
<para>
|
||||
Can we improve this? Well, for one, it is a bit confusing because
|
||||
once we have converted a line of text, our input no longer
|
||||
starts at the begining of the line. We can modify it to print
|
||||
starts at the beginning of the line. We can modify it to print
|
||||
a new line instead of a space after each <constant>0A</constant>:
|
||||
</para>
|
||||
|
||||
|
|
@ -2648,7 +2648,7 @@ This is the approach we will use in our program because it is very easy to do in
|
|||
</programlisting>
|
||||
|
||||
<para>
|
||||
This is possibly faster than hardcoding the address in the code
|
||||
This is possibly faster than hard coding the address in the code
|
||||
because the microprocessor does not have to fetch the address from
|
||||
the memory—it is already stored in one of its registers. I said
|
||||
<emphasis>possibly</emphasis> because with the caching modern
|
||||
|
|
@ -3636,7 +3636,7 @@ write:
|
|||
<para>
|
||||
Much of it is taken from <filename>hex.asm</filename> above. But there
|
||||
is one important difference: I no longer call <function>write</function>
|
||||
whenever I am outputing a line feed. Yet, the code can be
|
||||
whenever I am outputting a line feed. Yet, the code can be
|
||||
used interactively.
|
||||
</para>
|
||||
|
||||
|
|
@ -4774,7 +4774,7 @@ or <constant>4.4</constant> millimeters is close enough.
|
|||
<para>
|
||||
Additionally, we can decide that no matter how
|
||||
big a result we get, we only want to display four
|
||||
siginificant digits (or any other number
|
||||
significant digits (or any other number
|
||||
of them, of course). Alas, the <acronym>FPU</acronym>
|
||||
does not offer rounding to a specific number
|
||||
of digits (after all, it does not view the
|
||||
|
|
|
|||
Loading…
Reference in a new issue