mirror of
https://github.com/opnsense/src.git
synced 2026-06-08 16:22:46 -04:00
Spelling fixes.
This commit is contained in:
Mike Pritchard
parent
16ac318df7
commit
c48524c2aa
20 changed files with 44 additions and 44 deletions
|
|
@ -136,7 +136,7 @@ VT82C586, VT82C586B, VT82C596, VT82C596B, VT82C686, VT82C686A, VT82C686B, VT8231
|
|||
.Pp
|
||||
Unknown ATA chipsets are supported in PIO modes, and if the standard
|
||||
busmaster DMA registers are present and contain valid setup, DMA is
|
||||
also enabled, although the max mode is limitted to UDMA33, as it is
|
||||
also enabled, although the max mode is limited to UDMA33, as it is
|
||||
not known what the chipset can do and how to program it.
|
||||
.Pp
|
||||
The
|
||||
|
|
@ -202,7 +202,7 @@ Static device numbering
|
|||
kernel option)
|
||||
reserves a number for each possibly connected disk,
|
||||
even when not present.
|
||||
This is useful in hotswap senarios
|
||||
This is useful in hotswap scenarios
|
||||
where disks should always show up as the same numbered device,
|
||||
and not depend on attach order.
|
||||
.Sh SEE ALSO
|
||||
|
|
|
|||
|
|
@ -306,7 +306,7 @@ See
|
|||
.Xr wicontrol 8
|
||||
for information on different regulatory domains.
|
||||
Different regulatory domains may not be able to communicate with each
|
||||
other with 802.11a as different regualtory domains do not necessarily
|
||||
other with 802.11a as different regulatory domains do not necessarily
|
||||
have overlapping channels.
|
||||
.Pp
|
||||
Revision A1 of the D-LINK DWL-G520 and DWL-G650 are based on an
|
||||
|
|
@ -318,7 +318,7 @@ The algorithm used to select the rate for transmitted packets is
|
|||
very simplistic.
|
||||
There is no software retransmit; only hardware retransmit is used.
|
||||
Contributors are encouraged to replace the existing rate control algorithm
|
||||
with a better one (hint: all the information needed is availble to the driver).
|
||||
with a better one (hint: all the information needed is available to the driver).
|
||||
.Pp
|
||||
The driver does not fully enable power-save operation of the chip;
|
||||
consequently power use is suboptimal.
|
||||
|
|
|
|||
|
|
@ -64,8 +64,8 @@ The AX88172 is a USB 2.0 device which contains a 10/100
|
|||
ethernet MAC with MII interface and is designed to work with both
|
||||
ethernet and HomePNA transceivers.
|
||||
The AX88172 will operate with
|
||||
both USB 1.x and USB 2.0 controllers, however performace with 1.x
|
||||
contollers will be limited since the USB 1.x standard specifies a
|
||||
both USB 1.x and USB 2.0 controllers, however performance with 1.x
|
||||
controllers will be limited since the USB 1.x standard specifies a
|
||||
maximum transfer speed of 12Mbps.
|
||||
Users with USB 1.x controllers should therefore not expect to actually
|
||||
achieve 100Mbps speeds with these devices.
|
||||
|
|
|
|||
|
|
@ -207,7 +207,7 @@ This must not be zero and not larger than 65536.
|
|||
.El
|
||||
.Sh CAVEATS
|
||||
When putting a HE155 into a 64-bit 66MHz PCI slot the machine may hang.
|
||||
This occures very early in the POST so that even the display does not turn on.
|
||||
This occurs very early in the POST so that even the display does not turn on.
|
||||
The HE155 runs only in 33MHz slots (either 32 or 64-bit).
|
||||
HE622 cards work just fine in 64-bit slots.
|
||||
.Pp
|
||||
|
|
|
|||
|
|
@ -110,7 +110,7 @@ Instead, the 9751 is only capable of doing compression.
|
|||
Since we do not currently attempt to use any of these chips to do
|
||||
compression, the 9751-based cards are not useful.
|
||||
.Pp
|
||||
Support for the 7955 and 7956 is incomplete; the asymetric crypto
|
||||
Support for the 7955 and 7956 is incomplete; the asymmetric crypto
|
||||
facilities are to be added and the performance is suboptimal.
|
||||
.Sh HISTORY
|
||||
The
|
||||
|
|
|
|||
|
|
@ -134,7 +134,7 @@ Enable/disable ICMP replies received via broadcast or multicast.
|
|||
Defaults to false.
|
||||
.It Va reply_src
|
||||
.Pq Vt str
|
||||
An interface name used for the ICMP reply source in reponse to packets
|
||||
An interface name used for the ICMP reply source in response to packets
|
||||
which are not directly addressed to us.
|
||||
By default continue with normal source selection.
|
||||
.El
|
||||
|
|
|
|||
|
|
@ -327,7 +327,7 @@ modifying these settings.
|
|||
.Pp
|
||||
Ports are allocated at random within the specified port range in order
|
||||
to increase the difficulty of random spoofing attacks.
|
||||
In scenarios such as benchmarking, this behavior may be undesireable.
|
||||
In scenarios such as benchmarking, this behavior may be undesirable.
|
||||
In these cases,
|
||||
.Va net.inet.ip.portrange.randomized
|
||||
can be used to toggle randomization off.
|
||||
|
|
@ -551,7 +551,7 @@ for more information on network byte order.
|
|||
If the
|
||||
.Va ip_id
|
||||
field is set to 0 then the kernel will choose an
|
||||
appopriate value.
|
||||
appropriate value.
|
||||
If the header source address is set to
|
||||
.Dv INADDR_ANY ,
|
||||
the kernel will choose an appropriate address.
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@
|
|||
.Os
|
||||
.Sh NAME
|
||||
.Nm led
|
||||
.Nd API for manipulating LED's, lamps and other announciators.
|
||||
.Nd API for manipulating LED's, lamps and other annunciators.
|
||||
.Sh SYNOPSIS
|
||||
.In dev/led/led.h
|
||||
.Bd -literal
|
||||
|
|
@ -49,12 +49,12 @@ typedef void led_t(void *priv, int onoff);
|
|||
The
|
||||
.Nm
|
||||
driver provides generic support for handling LEDs, lamps and other
|
||||
announciators.
|
||||
annunciators.
|
||||
.Pp
|
||||
The hardware driver must supply a function to turn the announciator on and off
|
||||
The hardware driver must supply a function to turn the annunciator on and off
|
||||
and the device
|
||||
.Va name
|
||||
of the announciator relative "/dev/led/".
|
||||
of the annunciator relative "/dev/led/".
|
||||
The
|
||||
.Va priv
|
||||
argument is passed back to this on/off function and can be used however
|
||||
|
|
@ -64,24 +64,24 @@ The lamp can be controlled by opening and writing ascii strings to the
|
|||
"/dev/led/bla" device.
|
||||
.Pp
|
||||
In the following we will use this special notation to indicate the resulting
|
||||
output of the announciator:
|
||||
output of the annunciator:
|
||||
.Bl -tag -width Ds -offset indent -compact
|
||||
.It Ic *
|
||||
The announciator is on for 1/10th secound.
|
||||
The annunciator is on for 1/10th second.
|
||||
.It Ic _
|
||||
The announciator is off for 1/10th secound.
|
||||
The annunciator is off for 1/10th second.
|
||||
.El
|
||||
.Pp
|
||||
State can be set directly, and since the change happens immediately,
|
||||
it is possible to flash the announciator with very short periods and
|
||||
it is possible to flash the annunciator with very short periods and
|
||||
synchronize it with program events.
|
||||
It should be noted that there is a non-trivial overhead, so this may
|
||||
not be usable for benchmarking or measuring short intervals.
|
||||
.Bl -tag -width Ds -offset indent -compact
|
||||
.It Ic 0
|
||||
Turn the announciator off immediately.
|
||||
Turn the annunciator off immediately.
|
||||
.It Ic 1
|
||||
Turn the announciator on immediately.
|
||||
Turn the annunciator on immediately.
|
||||
.El
|
||||
.Pp
|
||||
Flashing can be set with a given period. The pattern continues endlessly.
|
||||
|
|
@ -107,10 +107,10 @@ ten pulses. Between digits a one second pause and after the last
|
|||
digit a two second pause after which the sequence is repeated.
|
||||
.It Ic s%s
|
||||
string.
|
||||
This gives full control over the announciator.
|
||||
Letters 'A' ... 'J' turns the announciator on for from 1/10th to one full
|
||||
This gives full control over the annunciator.
|
||||
Letters 'A' ... 'J' turns the annunciator on for from 1/10th to one full
|
||||
second.
|
||||
Letters 'a' ... 'j' turns the announciator off for 1/10th
|
||||
Letters 'a' ... 'j' turns the annunciator off for 1/10th
|
||||
to one full second.
|
||||
Unless terminated with a '.', the sequence is immediately repeated.
|
||||
.It Ic m%s
|
||||
|
|
|
|||
|
|
@ -103,7 +103,7 @@ option and more than 4 gigabytes of memory.
|
|||
.Pp
|
||||
Many parameters which determine how memory is used in the kernel are based on
|
||||
the amount of physical memory.
|
||||
The formulas used to determine the values of these paramters for specific
|
||||
The formulas used to determine the values of these parameters for specific
|
||||
memory configurations may not take into account the fact there may be more
|
||||
than 4 gigabytes of memory, and may not scale well to these memory
|
||||
configurations.
|
||||
|
|
|
|||
|
|
@ -90,7 +90,7 @@ is prepended to the actual data.
|
|||
.It Dv output
|
||||
This is a connection to the raw output stream to the network device.
|
||||
If this hook is connected, all outgoing packets are handed over to
|
||||
the netgraph system and delivered to the hook instead of beeing delivered
|
||||
the netgraph system and delivered to the hook instead of being delivered
|
||||
to the ATM driver.
|
||||
An
|
||||
.Dv atm_pseudohdr
|
||||
|
|
@ -262,7 +262,7 @@ This hook must already be connected.
|
|||
and
|
||||
.Dv vci
|
||||
are the respective VPI and VCI values to use for the ATM cells. They must be
|
||||
withing the range, given by the
|
||||
within the range, given by the
|
||||
.Dv maxvpi
|
||||
and
|
||||
.Dv maxvci
|
||||
|
|
|
|||
|
|
@ -48,7 +48,7 @@ Each Bluetooth module might add its own variables to the tree.
|
|||
A read-only integer variable that shows the current version of the
|
||||
Bluetooth stack.
|
||||
.It Va net.bluetooth.hci.command_timeout
|
||||
A read-write interger variable that controls the Host Controller Interface
|
||||
A read-write integer variable that controls the Host Controller Interface
|
||||
(HCI) command timeout (in seconds), i.e. how long the HCI layer will wait
|
||||
for the
|
||||
.Dv Command_Complete
|
||||
|
|
|
|||
|
|
@ -361,7 +361,7 @@ Returns current packet mask.
|
|||
Sets the value of the role switch.
|
||||
Role switch is enabled when this value is not zero.
|
||||
This is the default state.
|
||||
Note that actual role switch at Bluetooth link level will only be perfomed if
|
||||
Note that actual role switch at Bluetooth link level will only be performed if
|
||||
hardware supports role switch and it was enabled.
|
||||
.It NGM_HCI_NODE_GET_ROLE_SWITCH
|
||||
Returns the value of the role switch for the node.
|
||||
|
|
|
|||
|
|
@ -230,7 +230,7 @@ The upper layer protocol must populate
|
|||
.Va token .
|
||||
L2CAP node will queue request and start processing.
|
||||
Later, when response is
|
||||
ready or timeout has occured, L2CAP node will create new Netgraph message, set
|
||||
ready or timeout has occurred, L2CAP node will create new Netgraph message, set
|
||||
.Va token
|
||||
and
|
||||
.Dv NFG_RESP
|
||||
|
|
|
|||
|
|
@ -51,7 +51,7 @@ This is a thin sub-layer between the SSCOP (see
|
|||
and the UNI signalling.
|
||||
This node does not really implement a protocol but
|
||||
provides a mapping between the signals at the upper layer of the SSCOP and
|
||||
the signals, the UNI expectes at its lower layer.
|
||||
the signals, the UNI expects at its lower layer.
|
||||
It also provides default values for the parameters of the SSCOP.
|
||||
.Pp
|
||||
After creation of the node, the SSCF instance must be created by sending
|
||||
|
|
@ -104,7 +104,7 @@ is a signal that comes out of the node
|
|||
.Ql ->
|
||||
or is sent by the node user to the node
|
||||
.Ql <- .
|
||||
The type of data expected for the signal is specified in parantheses.
|
||||
The type of data expected for the signal is specified in parentheses.
|
||||
This data starts at the
|
||||
.Fa data
|
||||
field of the message structure.
|
||||
|
|
|
|||
|
|
@ -58,7 +58,7 @@ node has three hooks with fixed names:
|
|||
.It Dv lower
|
||||
This hook is the interface of the UNI protocol to the transport layer of
|
||||
the ATM control plane.
|
||||
The node expectes the interface exported by
|
||||
The node expects the interface exported by
|
||||
.Xr ng_sscfu 4
|
||||
at this hook.
|
||||
.It Dv upper
|
||||
|
|
@ -91,9 +91,9 @@ four kinds of signals: requests, responses, indications and confirmations.
|
|||
These signals are usually triggered either by external events (receiving a
|
||||
message) or internal events (a timer or another signal).
|
||||
This scheme works
|
||||
fine for user APIs that are entirely asynchronuous and in cases, where
|
||||
fine for user APIs that are entirely asynchronous and in cases, where
|
||||
error handling is not taken into account.
|
||||
With synchronuous APIs and error
|
||||
With synchronous APIs and error
|
||||
handling, however there is a problem.
|
||||
If, for example, the application
|
||||
issues a request to setup a connection.
|
||||
|
|
@ -105,7 +105,7 @@ receive a message from the switch (a RELEASE, CONNECT, CALL PROCEEDING or
|
|||
ALERTING) or a timer in the UNI stack will time out.
|
||||
In any of these cases
|
||||
the UNI stack is supposed to report an event back to the application and
|
||||
the application will unblock (in the case of a synchronuous API) and handle
|
||||
the application will unblock (in the case of a synchronous API) and handle
|
||||
the event.
|
||||
The problem occurs, when an error happens.
|
||||
Suppose there is no
|
||||
|
|
@ -118,7 +118,7 @@ for each signal sent from the application to the stack, the stack will
|
|||
respond with an error code.
|
||||
If this code is zero, the stack has accepted
|
||||
the signal and the application may block, if the code is non-zero, the signal
|
||||
is effectivly ignored and the code describes, what was wrong.
|
||||
is effectively ignored and the code describes, what was wrong.
|
||||
This system
|
||||
makes it very easy to make a blocking interface out of the message based
|
||||
netgraph interface.
|
||||
|
|
@ -405,7 +405,7 @@ More testing needed.
|
|||
.It
|
||||
PNNI not yet implemented.
|
||||
.It
|
||||
Need to implement connection modification and the Q.2931 amandements.
|
||||
Need to implement connection modification and the Q.2931 amendments.
|
||||
.Sh AUTHORS
|
||||
The
|
||||
.Nm
|
||||
|
|
|
|||
|
|
@ -62,7 +62,7 @@ SMIT mode is only supported under OLDCARD now.
|
|||
.Sh HISTORY
|
||||
The
|
||||
.Nm
|
||||
driver has been developped for NetBSD/pc98 and ported for
|
||||
driver has been developed for NetBSD/pc98 and ported for
|
||||
.Fx .
|
||||
It first appeared in
|
||||
.Fx 3.4
|
||||
|
|
|
|||
|
|
@ -139,7 +139,7 @@ the network connection (e.g. a cable fault).
|
|||
The driver failed to allocate an mbuf for the receiver ring.
|
||||
.It "sis%d: no memory for tx list"
|
||||
The driver failed to allocate an mbuf for the transmitter ring when
|
||||
allocating a pad buffer or collapsing an mbuf chain into a clusisr.
|
||||
allocating a pad buffer or collapsing an mbuf chain into a cluster.
|
||||
.It "sis%d: chip is in D3 power state -- setting to D0"
|
||||
This message applies only to adapters which support power
|
||||
management.
|
||||
|
|
|
|||
|
|
@ -368,7 +368,7 @@ typically added to the raw calculation to take into account
|
|||
occasional variances that the
|
||||
.Tn SRTT
|
||||
(smoothed round-trip time)
|
||||
is unable to accomodate, while the minimum specifies an
|
||||
is unable to accommodate, while the minimum specifies an
|
||||
absolute minimum.
|
||||
While a number of
|
||||
.Tn TCP
|
||||
|
|
@ -395,7 +395,7 @@ unnecessary packets in the network.
|
|||
This option is recommended if you
|
||||
are serving a lot of data over connections with high bandwidth-delay
|
||||
products, such as modems, GigE links, and fast long-haul WANs, and/or
|
||||
you have configured your machine to accomodate large
|
||||
you have configured your machine to accommodate large
|
||||
.Tn TCP
|
||||
windows.
|
||||
In such
|
||||
|
|
|
|||
|
|
@ -44,7 +44,7 @@ The
|
|||
.Nm
|
||||
device driver provides support for various classes of UARTs implementing the
|
||||
EIA RS-232C (CCITT V.24) serial communications interface.
|
||||
Each such interface is controlled by a seperate and independent instance of
|
||||
Each such interface is controlled by a separate and independent instance of
|
||||
the
|
||||
.Nm
|
||||
driver.
|
||||
|
|
|
|||
|
|
@ -84,7 +84,7 @@ Twisted pair diagnostic loopback. Connects the high speed receive data to the
|
|||
high speed transmit data. All received data is sent back. The receiver
|
||||
operates normally.
|
||||
.It Dv UTP_LOOP_PATH (0x20)
|
||||
Diagnostic path loopback. This connectes the receiver input to the transmitter
|
||||
Diagnostic path loopback. This connects the receiver input to the transmitter
|
||||
output just between the path overhead processor and the byte mux. The
|
||||
transmitter operates normally.
|
||||
.El
|
||||
|
|
|
|||
Loading…
Reference in a new issue