helenos-nicf team mailing list archive
-
helenos-nicf team
-
Mailing list archive
-
Message #00183
spellchecker diff
=== modified file 'uspace/doc/helnet.txt'
--- uspace/doc/helnet.txt 2011-08-31 16:46:17 +0000
+++ uspace/doc/helnet.txt 2011-08-31 17:59:32 +0000
@@ -13,7 +13,7 @@
want to write NIC drivers or software tightly cooperating with lower layers of
network stack (such as firewalls or the networking stack itself). This manual
also contains the description of DMA support developed by part of NIC
-developement support.
+development support.
Goals and achievements of the project
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -66,7 +66,7 @@
HelenOS networking architecture
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Unlike most monolitic operating systems the network stack in HelenOS is not a
+Unlike most monolithic operating systems the network stack in HelenOS is not a
part of the kernel. As a matter of fact it is distributed between several
processes, one for each layer and protocol - these are called *modules* in the
network stack architecture. Originally there was an option to bundle some of
@@ -176,9 +176,9 @@
^^^^^^^^^^^^^^^^^^
The interrupts are mostly processed in the userspace. In the case of level
-triggered devices there is a necessarity of handling the interrupt before
+triggered devices there is a necessity of handling the interrupt before
leaving the kernel - the device must clear the interrupt before kernel enables
-the interrupts again. The interrupt handling is devided to two parts - kernel
+the interrupts again. The interrupt handling is divided to two parts - kernel
part defined by pseudocode in $irq_code_t$ structure instance and
userspace handler, both passed to DDF and kernel by
$register_interrupt_handler()$ function. The driver must include
@@ -193,22 +193,22 @@
The HelenOS uses the buddy allocator for frame allocation, the allocation
is possible by the power of two chunks of frames only.
-The virtual address space is devided into continuous adress space areas
+The virtual address space is divided into continuous address space areas
represented by $as_area_t$ structure. The different areas needs different
management thus memory backend is assigned to each area. The backend is
-responsible for the page faults handling, propper sharing, resizing or
+responsible for the page faults handling, proper sharing, resizing or
destroying whole area. The example of such backend is anonymous space area
backend ($anon_backend$) implemented in the %kernel/generic/src/backend_anon.c%
handling common memory without specific requirements for physical addresses.
The memory sharing is invoked by the IPC communication between the participated
-processes, the kernel waits untill the sharing is confirmed and crates new
+processes, the kernel waits until the sharing is confirmed and crates new
memory area managed by the same backend as the area in the original process.
The backend is notified about area sharing during the first sharing request and
it should initialize structure containing the memory sharing information.
<<<<
-NIC Framework architecure
+NIC Framework architecture
-------------------------
NIC Framework evolved from the former network stack architecture exploiting the
merits of the Device Driver Framework. Its first objective was to design and
@@ -224,8 +224,8 @@
~~~~~~~~~~~~~~~~~~
The framework consists of the NIC interface added to *DDF* and *+libnic+*
library which contains default handlers for the most of NIC and DDF interface
-parts and supporting functions for the NIC driver developement. The structure of
-driver implemented by using NIC framewor is shown in <<nicf_overview_img>>.
+parts and supporting functions for the NIC driver development. The structure of
+driver implemented by using NIC framework is shown in <<nicf_overview_img>>.
[[nicf_overview_img]]
.Driver structure overview
@@ -233,7 +233,7 @@
One goal of the framework was the reduction of hand written driver code thus the
default implementations were added to all possible interface functions. The
-NIC interface will be decribed in <<nic_if_intro>> and <<nic_interface>>
+NIC interface will be described in <<nic_if_intro>> and <<nic_interface>>
, the libnic will be described in <<libnic>>.
The DMA support library and other tools will be described in <<DMA_doc>>.
@@ -244,7 +244,7 @@
~~~~~~~~~~~~~~~~~~~~~~
Here is a brief example how is application request - procedure call - translated into IPC and back into procedure call on the driver side.
Requests which send and receive multiple arguments and blocks of data are more complicated, of course.
-The overall functionality is a part of the Device Driver Framework but the actuall implementation of the RPC stubs was required during
+The overall functionality is a part of the Device Driver Framework but the actual implementation of the RPC stubs was required during
the NIC Framework. Detailed description of concrete methods in the interface
will follow in <<nic_interface>>, the table of default handlers and its
requirements is in the <<handlers_summary>>.
@@ -252,7 +252,7 @@
Application side
^^^^^^^^^^^^^^^^
-All IPC communitation encapsulation was added to *+libc+* to the
+All IPC communication encapsulation was added to *+libc+* to the
%<device/nic.h>%. The function marshalls arguments into an IPC call together
with the interface ($DEV_IFACE_ID(NIC_DEV_IFACE)$) and method identifiers
($NIC_SEND_MESSAGE$ in the example below). Then it verifies that the return
@@ -290,8 +290,8 @@
When a IPC request comes the service routine is picked from the *remote interface*.
This routine is responsible for IPC communication,
decoding parameters and obtaining all request-related data and
-calling the propper callback from nic interface. The *remote interface* functions
-will be refered as *remote functions* in further text.
+calling the proper callback from nic interface. The *remote interface* functions
+will be called as *remote functions* in further text.
Both interfaces were added to *+libdrv+* to the %uspace/lib/drv% directory.
*Remote interface* is defined in %uspace/lib/drv/generic/remote_nic.c% and it consists
@@ -309,7 +309,7 @@
nic_iface_t *nic_iface = (nic_iface_t *) iface;
/* Decode callback argument from the IPC message */
packet_id_t packet_id = (packet_id_t) IPC_GET_ARG2(*call);
- /* Call the propper high-level callback */
+ /* Call the proper high-level callback */
int rc = nic_iface->send_message(dev, packet_id);
/* Return the result */
async_answer_0(callid, rc);
@@ -338,7 +338,7 @@
be used for the device. The $connect_to_nil()$ callback is responsible for
connecting driver to the NIL service given as parameter.
-All of this is provided by default implmenetation $nic_connect_to_nil_impl()$
+All of this is provided by default implementation $nic_connect_to_nil_impl()$
in the NIC framework, no additional code in driver is required in common cases.
Device states
@@ -361,7 +361,7 @@
Packet sending and receiving
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-The packet sending and recception is allowed only in *active* state.
+The packet sending and reception is allowed only in *active* state.
The mandatory $send_message()$ callback must be implemented for sending packets
to the network.
@@ -381,7 +381,7 @@
|===================
|Mode | Enumeration value |Description
|*immediate* | $NIC_POLL_IMMEDIATE$ |The device polling is invoked by interrupt immediately after packet reception
-|*on demand* | $NIC_POLL_ON_DEMAND$ |The device polling is invoked expicitely by $poll_now()$ callback
+|*on demand* | $NIC_POLL_ON_DEMAND$ |The device polling is invoked explicitly by $poll_now()$ callback
|*periodic* | $NIC_POLL_PERIODIC$ |The device polling is invoked in specific periodic intervals
|*software periodic* | $NIC_POLL_SOFTWARE_PERIODIC$ | The same as *periodic* but the period is invoked by software
|===================
@@ -394,7 +394,7 @@
Filtering
^^^^^^^^^
The driver can set what kind of packets are accepted. This functionality is
-optional, the promiscuite mode (accept whatever comes) is supposed in the case
+optional, the promiscuity mode (accept whatever comes) is supposed in the case
the driver does not support this interface parts. The filtering of unicast
packets should be set by $unicast_set_mode()$ and obtained by
$unicast_get_mode()$. The possible modes are in <<unicast_modes_tab>>
@@ -440,7 +440,7 @@
The NIC controllers can set its speed, duplexity (full/half duplex) and role
(master or slave, gigabit ethernet only), which can be either set by hand or
autonegotiated. The autonegotiation is the preferred way and the driver should
-enable it by default if supports, but this is only recomendataion.
+enable it by default if supports, but this is only recommendation.
Implementation of this functionality is only optional.
The callback for manual setting is $set_operation_mode()$, the mode can be
@@ -449,7 +449,7 @@
autonegotiation is forced by $autoneg_restart()$ and the current autonegotiation
setting can be obtained from $autoneg_probe()$. If the autonegotiation is
enabled, the manual setting is discarded and replaced by the autonegotiated, if
-the manual setting is forced, autonegotiation should be disabled automaticaly.
+the manual setting is forced, autonegotiation should be disabled automatically.
The autonegotiation advertisement is passed by bitmask of $ETH_AUTONEG_$ macros
defined in %<net/eth_phys.h>% in *+libc+*. For example
@@ -458,12 +458,12 @@
means "all supported by driver". The driver should return error value if some
unsupported mode is requested rather than silently enable unsupported mode.
-The flow control can be also set manualy or be autonegotiated. In some
+The flow control can be also set manually or be autonegotiated. In some
autonegotiated modes the controller can allow setting flow control modes. The
flow control setting should not disable autonegotiation, error code should be
-returned instaed. The flow control setting can be taken by $get_pause()$
+returned instead. The flow control setting can be taken by $get_pause()$
callback, it can be set by $set_pause()$ callback. When forced time of pause
-packet is not supported by the controller (but the pause packet transmittion can
+packet is not supported by the controller (but the pause packet transmition can
be enabled), the nearest possible time supported should be set. The time value 0
lets driver choose the best suitable time.
@@ -473,7 +473,7 @@
$nic_device_stats_t$ structure. The statistics can be requested by $get_stats()$
callback.
-Another usefull informations, like supported ethernet physical layers or
+Another useful informations, like supported ethernet physical layers or
supported autonegotiation modes, can be requested by $get_device_info()$
callback. The actual status of cable connection should be obtained by
$get_cable_state()$ callback.
@@ -499,7 +499,7 @@
through $vlan_set_tag()$ callback. The presence of desired tag (maybe stripped)
should be indicated in the offload field of the packet.
-Similary, the packets can be just filtered according to the tag. Because
+Similarly, the packets can be just filtered according to the tag. Because
the 12-bit identifier space is pretty narrow, the filtering can be perfectly
specified through a 512-byte mask. See callbacks $vlan_set_mask()$ and
$vlan_get_mask()$.
@@ -522,7 +522,7 @@
NIC driver structure and libnic
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The *+libnic+* library was developed for the NIC controller drivers
-developement. It contains some helper stuff and default implementation of the
+development. It contains some helper stuff and default implementation of the
NIC interface functionalities. Its source root directory is %uspace/lib/nic%.
The header file the driver should include is %<nic.h>% where all functions
supposed to be used by driver are defined. The rest of headers is considered
@@ -543,7 +543,7 @@
handlers are able to provide whole request.
The description of default handlers is placed in the feature
-support description. The framework convetion is that the default handler
+support description. The framework convention is that the default handler
of "$callback()$" is implemented by "$nic_callback_impl()$" in file
%uspace/lib/nic/generic/nic_impl.c%. The brief summary of the default handlers
requirements can be found in <<handlers_summary>>.
@@ -552,13 +552,13 @@
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The *+libnic+* contains function $nic_driver_init()$ which should be called when
the driver starts - it initializes internal *+libnic+* structures like internal
-logging and initalizes packet manager. Next the driver should initialize
+logging and initializes packet manager. Next the driver should initialize
all DDF interfaces and call $nic_driver_implement()$ function which replaces
unimplemented functions by default implementations if possible.
Device Initialization Support
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Device initialization shoud be done in $add_device()$ callback. The %nic_t%
+Device initialization should be done in $add_device()$ callback. The %nic_t%
instance should be created by $nic_create_and_bind()$ function, which also
initializes it and connects to the DDF device structures,
From this moment the conversion between $nic_t$, $ddf_fun_t$ and $ddf_dev_t$ can
@@ -573,7 +573,7 @@
and deallocates the memory.
The device should report its default MAC address by $nic_report_address()$
-to the framework to allow propper checking of request validity, this should also
+to the framework to allow proper checking of request validity, this should also
be done together with all MAC address changes.
As the final step the device should connect itself to the NET server and
@@ -582,7 +582,7 @@
In the following $device_added()$ callback the device should call the
$nic_ready()$ to notify NET service that the driver is prepared to work. The
-default implmenetation for $device_added()$ callback provide this notification.
+default implementation for $device_added()$ callback provide this notification.
Device state handling
^^^^^^^^^^^^^^^^^^^^^
@@ -595,15 +595,15 @@
When moving to the *stopped* state the framework resets all the settings to its
-defaults and calls the propper callbacks to propagate the settings to the
+defaults and calls the proper callbacks to propagate the settings to the
driver. In the $on_stopped()$ state the driver should reset the controller. When
moving to the *down* state the driver can turn the device off but the controller
settings must be restored when activating again.
-Packet transmittion support
+Packet transmition support
^^^^^^^^^^^^^^^^^^^^^^^^^^^
The packets to send are given to the framework by $send_message()$ callback by
-ID of the first packet in the queue to send. The default implemnetation of this
+ID of the first packet in the queue to send. The default implementation of this
callback checks the device state, then goes through the queue, checks each
packet validity, obtains its data from the NET server in $packet_t$ structure,
and goes through all packets in the queue to send and calls $write_packet()$
@@ -614,12 +614,12 @@
$nic_set_write_packet_handler()$ function during the device
initialization.
-If the driver is not able to send more packets because of full transmittion
+If the driver is not able to send more packets because of full transmition
buffers, it can set the "Transmitter busy" sign by $nic_set_tx_busy()$ function,
-the default implemnetation will discards packets untill the busy sign is cleared
+the default implementation will discards packets until the busy sign is cleared
(set to 0).
-After the packet transmittion is finished, the $nic_release_packet()$ should be
+After the packet transmition is finished, the $nic_release_packet()$ should be
call to release the packet from the system. It is not done by default
implementation because sometimes the packet cannot be released until the interrupt
comes to confirm its transmission. Here should be the packet released in the
@@ -634,7 +634,7 @@
$nic_alloc_packet()$ encapsulates the communication with the server. The most of
controllers receive more than one packet during one poll event. The received
packets are stored in $nic_frame_t$ structure (further referenced as
-packet frame) contaning the $packet_t$ field and the connection to linked list
+packet frame) containing the $packet_t$ field and the connection to linked list
of received packets. The whole linked list of packets is represented by
$nic_frame_list_t$ type, the $nic_alloc_frame_list()$ and
$nic_frame_list_append()$ encapsulates the work with the list.
@@ -672,7 +672,7 @@
The filters are controlled through $unicast_set_mode()$, $multicast_set_mode()$,
$broadcast_set_mode()$, $blocked_sources_set()$ and $vlan_set_mask()$.
-The framwork checks the requested setting and if valid the driver is notified
+The framework checks the requested setting and if valid the driver is notified
to do the hardware setting by $on_unicast_mode_change()$, $on_multicast_mode_change()$,
$on_broadcast_mode_change()$, $on_blocked_sources_change()$ and
$on_vlan_mask_change()$ settings.
@@ -686,7 +686,7 @@
$nic_report_hw_filtering()$ method - if the driver provides exact filtering as
requested the software filtering will be skipped by the framework.
-The current filtering setting is returned by default implmenetations
+The current filtering setting is returned by default implementations
of $unicast_get_mode()$, $multicast_get_mode()$, $broadcast_get_mode()$,
$blocked_sources_get()$ and $vlan_get_mask()$ functions, no code in driver is required.
@@ -704,7 +704,7 @@
callback. The *immediate* and *on demand* modes should be supported by driver.
If the *periodic* or *software periodic* is not supported by driver, the
framework tries to switch the driver to *on demand* mode by
-$on_poll_mode_change()$ request and start fibril which periodicaly calls
+$on_poll_mode_change()$ request and start fibril which periodically calls
$on_poll_request()$ on the device.
The default $poll_get_mode()$ handler just returns last mode set successfully.
@@ -713,7 +713,7 @@
during the initialization.
Driver could report current polling mode by calling $nic_report_poll_mode()$.
-This is usefull for setting default polling mode during the initialization.
+This is useful for setting default polling mode during the initialization.
[[nic_t_access]]
Accessing the nic_t structure
@@ -744,7 +744,7 @@
interfaces, used in higher layers of network stack. Meanwhile the NIC driver
obtains resources for the device from parent bus, registers device in DevMan
and informs the NET service that the device is ready for operation.
-*NET* spawns apropriate link-layer (*NIL*) protocol module (*ETH* as for
+*NET* spawns appropriate link-layer (*NIL*) protocol module (*ETH* as for
Ethernet) and this requests backward connection and device's address. After
that the device is set to the active state (see below), notifying higher
layers of network stack about a new possible routing path through this device.
@@ -776,15 +776,15 @@
Userspace memory allocation
^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Userspace interface of DMA frammework (except DMA controller driver) is defined
+Userspace interface of DMA framework (except DMA controller driver) is defined
in %dma.h% and contained in %libc.a%.
First operation before using DMA framework should be it's initialization. There
is a procedure $dma_allocator_init()$, which initializes all internal
structures and waits for connection to DMA server. In current implementation it
-is not neccessary to call when driver uses only syscall wrappers.
+is not necessary to call when driver uses only syscall wrappers.
-For allocating continguous memory areas usable for basic DMA transfer we
+For allocating continuous memory areas usable for basic DMA transfer we
have introduced basic syscall $dma_allocate()$. It allocates continuous physical
memory area. From this memory is created a memory area at passed virtual
address.
@@ -849,7 +849,7 @@
-------------
Because of semantics of $dma_lock()$ we suppose, that many users would use some
-wrappers of it, which locks all memory area, not just longes continguous. This
+wrappers of it, which locks all memory area, not just continuous area. This
operation can be done this way:
@@ -880,7 +880,7 @@
}
-------------
-Of course sometimes it is necessary to work with direcly allocated and mapped
+Of course sometimes it is necessary to work with direly allocated and mapped
memory:
[source,c]
@@ -897,7 +897,7 @@
memory.size = num_of_pages;
memory.mapping_flags = AS_AREA_READ | AS_AREA_WRITE;
- /* Allocate area num_of_pages large, whith flags
+ /* Allocate area num_of_pages large, with flags
* AS_AREA_READ | AS_AREA_WRITE and from any address
* range (the parameter 0) */
if ((dma_allocate_anonymous(&memory, 0)) != EOK)
@@ -935,7 +935,7 @@
/*unlock the memory*/
if (dma_unlock(area, size_in, &size_out) != EOK)
- /*serios problem*/
+ /*serious problem*/
/* all memory is again released and kernel structures are clean*/
}
@@ -971,7 +971,7 @@
When a block of DMA memory is freed, first is searched tree of possible
neighbours and if there is a block which is neighbour of freed block and together
are part of a buddy these are merged. This procedure is repeated until some
-neighbor exists. If it does not, two cases are possible:
+neighbour exists. If it does not, two cases are possible:
* 1) There is some allocated and used block, so merged block is inserted back to
rests prepared for allocation
@@ -1096,8 +1096,8 @@
On memory area destroy (e.g. termination of process by a failure), pages
allocated for DMA transfer and locked for swapping, are unlocked and returned to
kernel memory allocator. Then they can be reused for another process. But device
-is still running and can rewrite them. So there should be way to aviod this
-behavior. Because of this there is a memory server which can share memory areas
+is still running and can rewrite them. So there should be way to avoid this
+behaviour. Because of this there is a memory server which can share memory areas
with other processes and this way protect them from deallocating.
The server is launched on bootstrap of HelenOS and is bound as a service.
@@ -1108,12 +1108,12 @@
process.
In other case, it means, the old instance of the same identificator was not
-correctly terminated. So the old id is returned and now the new instace has
+correctly terminated. So the old id is returned and now the new instance has
chance to reinitialize the device and then destroy all mapping.
The fact of returning old or new id is not reported to client because of forcing
to initialize the device always. After connecting to the DMA server the
-idetification of client is done only by it's unique id.
+identification of client is done only by it's unique id.
After successful connection can client also share memory to server and stop to
share it. For sharing is necessary address of shared memory area, offset
@@ -1130,9 +1130,9 @@
DMA server API:
^^^^^^^^^^^^^^
The API of DMA server is declared in %dma.h% and present in %libc.a%. For
-logging-in to DMA memory server is there procedur $dma_cli_register()$. It
-establishes connetion to server. Opposite to it is $dma_cli_unregister()$,
-which unregisters client from server. But unregistration is successfuly done
+logging-in to DMA memory server is there procedure $dma_cli_register()$. It
+establishes connection to server. Opposite to it is $dma_cli_unregister()$,
+which unregisters client from server. But unregistration is successful done
only when all memory already shared by calling process has been successfully
released.
@@ -1143,9 +1143,9 @@
$dma_cli_cleanup()$. It queries the server to release all memory already
allocated with the client.
-When a driver uses memory buffer, it can use memory locking by DMA servere.
+When a driver uses memory buffer, it can use memory locking by DMA server.
These locks persists driver exit. First is necessary initialize the DMA
-framework as described above. Than the application must donnect to DMA server
+framework as described above. Than the application must connect to DMA server
and clean possible residual memory areas:
[source,c]
@@ -1155,11 +1155,11 @@
int dev_init_procedure(....)
{
/*Obtain handle from server*/
- int rc = dma_cli_register("my unique string idetifier", &id);
+ int rc = dma_cli_register("my unique string identifier", &id);
if (rc != EOK)
/*Handle error*/
- /*Do device initialiazion, so it does not need any memory buffers*/
+ /*Do device initialization, so it does not need any memory buffers*/
dev_initialize_first_stage();
/*Tell the server, it can free all shared memory by this id*/
@@ -1234,11 +1234,11 @@
this moment is used second tree sorted by integer. This solution has been chosen
because of speed of comparing strings and integers and speed of passing integers
and string via IPC. Chosen structures are again generic AVL trees because they
-can simply implement comparision of string keys.
+can simply implement comparison of string keys.
Each logged in identifier has a list of locked areas. The list is again
implemented as a generic AVL tree, because it is quite fast and it can be
-powerfuly enhanced. Here the tree is sorted by hardware address of first locked
+powerfully enhanced. Here the tree is sorted by hardware address of first locked
page form described area. This is because it is most simple way of passing data
between client and server. Both of them knows this address and it is not
necessary to pass some other data from server to client.
@@ -1255,9 +1255,9 @@
controller.
The framework contains the set of IPC stubs and skeletons used by DDF framework.
-It is used for driving access to DMA controller driver. The framework is devided
+It is used for driving access to DMA controller driver. The framework is divided
into four basic parts - driver capabilities oriented call, channel oriented
-calls, device transfer oriented calls and memory oriented callse - and is
+calls, device transfer oriented calls and memory oriented calls - and is
declared in the %<device/dma_controller.h>% *libc* header file.
Driver capabilities oriented call
@@ -1269,7 +1269,7 @@
Channel oriented calls
^^^^^^^^^^^^^^^^^^^^^^
-DMA channel is entitiy representing slot for transfers. They can be physical
+DMA channel is entity representing slot for transfers. They can be physical
oriented (e.g. Intel 8237), where each channel has wires in the bus.
HelenOS DMA framework expects even logical channels, which are created by
software (the DMA controller driver). It is possible to imagine a channel
@@ -1279,10 +1279,10 @@
$dma_channel_t$ and it's internal structure is not important for user.
Procedure $dma_query_channels()$ queries server for a list of all channels
-available for transfers. When client has list of all chennels, it can call
+available for transfers. When client has list of all channels, it can call
$dma_occupy_channel()$ to ask server to allocate specified channel to it.
Every driver should use only channels allocated this way. When a channel is
-not needed anytime, it is necessary to call $dma_release_channel()$. It marks at
+not needed any time, it is necessary to call $dma_release_channel()$. It marks at
server the channel as free and usable for other processes.
Device transfer oriented calls
@@ -1297,13 +1297,13 @@
$dma_set_write_transfer()$ and $dma_add_write_transfer()$ requests the device to
memory transfers. The transfers requested by $_set$ functions are started
immediately, the currently processed transfer should be terminated, the
-transfers requested by $_add$ functions are added to the end of transfer reqeust
+transfers requested by $_add$ functions are added to the end of transfer request
queue on the channel.
-The transfer status can be obtained by $dma_check_tranfer_status()$ method.
+The transfer status can be obtained by $dma_check_transfer_status()$ method.
When the transfer is finished, server should after receiving this request
deallocate the transfer and it is not possible to check it's status again.
-The transfer can be canceled by $dma_cancel_transfer()$ - the running transfer
+The transfer can be cancelled by $dma_cancel_transfer()$ - the running transfer
is terminated, queued transfer is removed from the waiting queue and
deallocated.
@@ -1322,9 +1322,9 @@
call. On the other hand $dma_add_mem_cpy_transfer()$ adds transfer from physical
memory to physical memory to any suitable channel. When someone tries to rewrite
so transfer, the rewriting is delayed until this transfer is completed or the
-rewritten transfer is sent to anoter channel, or if it is permitted by flag the
+rewritten transfer is sent to another channel, or if it is permitted by flag the
rewritten transfer is delayed until rewriting transfer finishes. Of course this
-transfer can be explicitly canceled by user. Strongly recommended to use this
+transfer can be explicitly cancelled by user. Strongly recommended to use this
call.
DMA controller driver interface
@@ -1333,21 +1333,21 @@
device driver and DMA controller driver. It is placed in %libdrv.a% and
definition of the interface is in %<ops/dma_controller.h>% and
%<remote_dma_controller.h>%. The interface is mostly same as the the interface
-of the client part of the protocol, only poiter to $ddf_fun_t$ is added.
+of the client part of the protocol, only pointer to $ddf_fun_t$ is added.
-Server at initialization of new device instace should fill new instance of
+Server at initialization of new device instance should fill new instance of
$dma_iface_t$ with proper callbacks and behave as a drive in other ways.
Prototypes of that callbacks are at %<ops/dma_controller.h>%.
Writing basic driver using DMA bus mastering
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Basic driver does not use scather/gather technology, when you are writing so
+Basic driver does not use scatter/gather technology, when you are writing so
driver, follow these points:
-. initializie the DMA framework (by calling $dma_allocator_init()$)
+. initialize the DMA framework (by calling $dma_allocator_init()$)
. initialize the device and then call $dma_cli_cleanup()$.
-. allocate continguous buffers by $dma_allocate()$.
+. allocate continuous buffers by $dma_allocate()$.
. the buffers should be shared to the DMA server.
. if the driver uses DMA with external bus transfer driver, it should connect
to proper driver.
@@ -1361,10 +1361,10 @@
unsure, whether there is not any area shared to server, call
$dma_cli_cleanup()$ and then $dma_unregister()$.
-Writing driver using scather/gather
+Writing driver using scatter/gather
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Scather gather memory access is the most common way of using DMA at modern
+Scatter gather memory access is the most common way of using DMA at modern
systems containing PCI bus. The way of using DMA framework is similar to
preceding case, but little differs.
@@ -1382,7 +1382,7 @@
and deallocate old and send requests do DMA transfer driver. When shared
memory area is destroyed, server remembers it until it obtains explicit request
to free it. Memory, which is not released by application and server is unusable
-for further usage. The DMA tranfer driver can be polled by
+for further usage. The DMA transfer driver can be polled by
$remote_dma_check_transfer_status()$.
. release DMA channel if it has been allocated.
. disconnect from servers. Before it all shared memory should be freed so when
@@ -1393,13 +1393,13 @@
<<<<
Implemented and integrated drivers
----------------------------------
-The framework alone would be useless without any working drivers. Implementing example drivers for it provides both functional and mainly architectural testing, prooving framework's correctness and good design. This section describes several drivers we have implemented or ported to NICF.
+The framework alone would be useless without any working drivers. Implementing example drivers for it provides both functional and mainly architectural testing, proving framework's correctness and good design. This section describes several drivers we have implemented or ported to NICF.
Loopback
~~~~~~~~
In fact the loopback driver is not necessary. All packets that should be send through the loopback virtual device are immediately received by the same device and sent back up to the network stack. It does not use Ethernet module but its own special Nildummy module, which is just a simplified Ethernet module, so the looping could be done already in the Nildummy module.
-However, the architecture can be more symetric with loopback as separate driver, there are no exceptions needed for having loopback as a network interface. For example statistics are counted here using the NIC framework and any task can get them in the same way as from usual physical NIC. The design is cleaner at the expense of minor performance hit and that's the way HelenOS is going.
+However, the architecture can be more symmetric with loopback as separate driver, there are no exceptions needed for having loopback as a network interface. For example statistics are counted here using the NIC framework and any task can get them in the same way as from usual physical NIC. The design is cleaner at the expense of minor performance hit and that's the way HelenOS is going.
Note: Currently there is a bug in network stack causing all packets going to loopback to be sent twice. This is not a bug of the driver itself but probably an error in *IP* module. That's why if you try to +ping 127.0.0.1+ and then +nicconf lo --stats+ you will see 8 packets to be sent and received instead of 4, what you would expect.
@@ -1407,26 +1407,26 @@
~~~~~~~~~~~~~~~
RTL8139 is the network interface controller from the late 90's operating on
10/100M Ethernet. The advantage of this controller is its big availability and
-its emulation in QEMU (athough there some differences between real harware and
+its emulation in QEMU (although there some differences between real hardware and
QEMU emulator behaviour). The driver implements all features the NIC interface
allows, the default framework implementations are used when possible, the
hardware settings are used if possible to avoid unnecessary software emulation.
Although the controller supports DMA there are too strong restrictions for it
-that the driver implementation is using internal buffers. The transmittion
+that the driver implementation is using internal buffers. The transmition
buffer must be aligned to 4B boundary, unfortunately the packets obtained from
the higher layers are not aligned properly thus copying to internal properly
aligned buffer is used. For receiving only one huge buffer is used and the
-driver must copy the packet contents by itself. The both budders are allocated
+driver must copy the packet contents by itself. The both buffers are allocated
by DMA library and the controller reads/write the packet memory directly.
-The developement of the RTL8139 driver was tightly related to the developement
+The development of the RTL8139 driver was tightly related to the development
of NIC framework and some parts of code were moved to the *+libnic+*.
Controller Documentation Sources
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-The driver implementation is based primarilly on the RTL8139 datasheets
+The driver implementation is based primarily on the RTL8139 datasheets
footnote:[The datasheets for RTL8139B(L), RTL8139C(L) and RTL8139C(L)+] and
RTL8139 programming guide footnote:[RTL8139(A/B) Programming guide: (V0.1)]
published by Realtek company. Unfortunately the official documentation is
@@ -1446,12 +1446,12 @@
The driver implementation is in %uspace/drv/rtl8139% and consist of general
sources in %rtl8139_general.[ch]%, register constants definition in
-%rtl8139_defs.[ch]% and the driver implemnetation in %rtl8139_driver.[ch]%. The
+%rtl8139_defs.[ch]% and the driver implementation in %rtl8139_driver.[ch]%. The
general sources contains the functions used in rtl8139 implementation not
related to the hardware and in future can be simply moved to the more general
library.
-The driver uses NIC framework structures, rtl8139 specific data are strored in
+The driver uses NIC framework structures, rtl8139 specific data are stored in
instance of %rtl8139_t% structure defined in %rtl8139_driver.h%. The
implementation boldly uses the default implementations of interface functions
of the framework and implements only the callbacks which needs to touch
@@ -1469,18 +1469,18 @@
part of code, the policy locking $tx_lock$ first and $rx_lock$ second was used
for deadlock prevention.
-The packet transmittion is provided in $rtl8139_write_packet()$ function set as
+The packet transmition is provided in $rtl8139_write_packet()$ function set as
callback to $nic_send_message_impl()$ providing packet preprocessing. In the
-controller There are 4 descriptors for sending packets choosed in the cyclic
+controller There are 4 descriptors for sending packets chosen in the cyclic
order, the first free buffer is used for the packet sending. There is 2kB
-buffer assigned to each descriptor, the data from the packet are coppied to the
+buffer assigned to each descriptor, the data from the packet are copied to the
buffer and controller is noticed it can copy the data by DMA bus mastering. If
there is no buffer free, the transmitter busy mark is set in NIC framework. In
the interrupt handler all previously used descriptors are checked for transfer
completion and marked as free, the transmitter busy is unset if some descriptor
was released.
-The reception is provided in $rtl8139_receive_packets()$. The controller coppies
+The reception is provided in $rtl8139_receive_packets()$. The controller copies
the packets to the cyclic buffer allocated by driver, if the buffer end is
reached the writing continues from the buffer start. When processing new packets
the driver obtains the last processed position in the buffer and the last
@@ -1491,7 +1491,7 @@
Other callbacks are implemented mostly by reading/writing controller registers,
the periodic polling mode is implemented by using internal timer increasing by
-external PCI clock tics.
+external PCI clock ticks.
Intel E1000
@@ -1513,14 +1513,14 @@
sources in %e1000.c% and hardware representation structures and constants
definitions in %e1000_defs.h%.
-Device registers are memmory mapped. PIO functions are used for accessing
+Device registers are memory mapped. PIO functions are used for accessing
them same way as IO ports. EERD registers is used for reading device EEPROM.
Because EERD description differs on some devices PCI device_id is used for
determining which variant to use.
For using interrupts manual mapping needs to be created. See PCI
improvements section. Interface could work without this mapping only in
-software periodic or on demmand polling mode.
+software periodic or on demand polling mode.
The driver uses four internal locks. $tx_lock$ for transmitter and $rx_lock$
receiver part of code. $ctrl_lock$ guards access to CTRL register and
@@ -1535,24 +1535,24 @@
Packet is preallocated before receiving and it's physical address is locked
by $dma_lock()$ and filled into receive descriptor ring. Once the packet is
-received, new empty packet is allocated. No packet copying is neccessary
-here either. Possible improvement could be to pospone allocation of some
+received, new empty packet is allocated. No packet copying is necessary
+here either. Possible improvement could be to postpone allocation of some
packets to avoid memory consumption. Question is whether it is worth the risk
of losing some packet. For example while receiving a lot of small packets.
The packet reception is provided in $e1000_receive_packets()$ function.
-It is possible to limit interrupt freqency (periodic polling mode) or disable
+It is possible to limit interrupt frequency (periodic polling mode) or disable
interrupts by using software polling. Default is at least 250 micro seconds
between interrupts.
There is 16 register array for receive address filtering. The first one
must be filled with interface address. In this driver top registers are used
for unicast addresses and the bottom registers are used for multicast
-addreses. Border between them is variable. When there is not enough space in
+addresses. Border between them is variable. When there is not enough space in
receive address array the device is switched into unicast or multicast
-promiscuous mode and NIC framwork does the filtering.
-For multicast there is possibility for using multivast array to prefilter
-trafic for framework. This was not implemented yet.
+promiscuous mode and NIC framework does the filtering.
+For multicast there is possibility for using multicast array to prefilter
+traffic for framework. This was not implemented yet.
Device supports adding and stripping VLAN tags. It is also possible to filter
specified VLAN tags while receiving.
@@ -1603,7 +1603,7 @@
| +-m --mac+ | Display/set MAC address for the device. The address must be specified as six two-digit hex numbers separated by hyphens (-) or colons (:), e.g. +12:34:56:AB:CD:EF+.
| +-o --opmode+ | Display/set operation mode for the device. The argument (if applied) must be in form +'speed','duplex','role'+, where +'speed'+ is the desired speed in Mbps, +'duplex'+ is either +full+ or +half+ and +'role'+ is +master+, +slave+ or +auto+.
| +-p --pollmode+ | Display/set device's polling mode. The argument (if applied) must be either +interrupts+ (default mode triggering interrupts when a new event is detected), +on_demand+ (some application manually polls the NIC for new events) or +periodic,'seconds','microseconds'+ (either the card or NICF automatically polls with period specified as the arguments).
-| +-s --state+ | Display/set NIC's state - one of these: +active+/+down+/+stopped+. +active+ is the usual operation state, +down+ state keeps settings but all communication (both outcomming and incomming) is disabled and going to the +stopped+ state results in a complete restart of the NIC.
+| +-s --state+ | Display/set NIC's state - one of these: +active+/+down+/+stopped+. +active+ is the usual operation state, +down+ state keeps settings but all communication (both outcoming and incoming) is disabled and going to the +stopped+ state results in a complete restart of the NIC.
| +-t --stats+ | Display statistics for the device.
|=====================
@@ -1698,7 +1698,7 @@
Address test
++++++++++++
-The address can be changed either directly by calling $nic_set_address()$ or implicitely by restarting the NIC (going to the $STOPPED$ state and back to $ACTIVE$). This test tries both ways and verifies that packets are received only for the set up address.
+The address can be changed either directly by calling $nic_set_address()$ or implicitly by restarting the NIC (going to the $STOPPED$ state and back to $ACTIVE$). This test tries both ways and verifies that packets are received only for the set up address.
[id="logging"]
Logging support
@@ -1707,11 +1707,11 @@
The necessity of some logging system was found in the USB team as well approximately in the same time as we have. They have developed much simpler system just as a wrapper to printing into separated file. This may be sufficient for logging actions of single process but because the network stack is scattered across many processes, we have decided to create a standalone service called *Logger* (%/srv/logger%), similar to e.g. +syslog+ in UNIX-like systems. This service gathers log records through IPC from multiple processes and stores them in single file together. This file uses binary format in order to allow easy filtering and faster seeking through that file. The logs can be probed through application +logview+ rather than by raw access to the file.
-Because of name-clash with USB team's logging support functions from our loggin system use prefix $nlog_$ instead of simple $log_$.
+Because of name-clash with USB team's logging support functions from our logging system use prefix $nlog_$ instead of simple $log_$.
With each message is recorded its severity (the levels were adopted from +syslog+), time, source task ID and labels associated with the record. These labels are added to the record automatically - there is one default and possibly more optional profiles in each task, with the labels recorded in the profile. Labels should form a hierarchy, for example for each driver's logs are tagged with labels +networking/nic+ and +drv/nic/+'driver_name'. Then you can filter for example only records with label +networking+, showing both records from the driver, *NET* service etc.
-Although the logging is working well for debugging, in stress tests it revealed to be radically slowing down. That's why the driver can easily supress unimportant records (with low level of severity) both at runtime and also at compile time by defining appropriate macros, completely removing the logging overhead. This can be also useful for example if you wan't to suppress debugging records from the *libnic* library but use your own messages at debug level in the driver itself.
+Although the logging is working well for debugging, in stress tests it revealed to be radically slowing down. That's why the driver can easily suppress unimportant records (with low level of severity) both at runtime and also at compile time by defining appropriate macros, completely removing the logging overhead. This can be also useful for example if you wan't to suppress debugging records from the *libnic* library but use your own messages at debug level in the driver itself.
Above mentioned application logview allows three modes of viewing the records:
@@ -1728,11 +1728,11 @@
PIO improvements
~~~~~~~~~~~~~~~~
$pio_<size>_read()$ and $pio_<size>_write()$ functions could now be used for
-accessing device memory and IO ranges. This is usefull for devices with
-memmory mapped registers.
+accessing device memory and IO ranges. This is useful for devices with
+memory mapped registers.
-This functions are used in interrupt pseudocode. Unfortunattely before using
-them there it is also neccessary to have address mapped in kernel space.
+This functions are used in interrupt pseudocode. Unfortunately before using
+them there it is also necessary to have address mapped in kernel space.
Since current HelenOS version has some memory limitations (see issue #3 and
#343 from the HelenOS mainline bug tracker
footnote:[http://trac.helenos.org/ticket/3]
@@ -1770,10 +1770,10 @@
PCI interface
~~~~~~~~~~~~~
-During developement of drivers the need of PCI configuration space access
+During development of drivers the need of PCI configuration space access
occured, the interface for reading and writing PCI configuration space registers
was added. Unfortunately the similar interface was developed and merged to the
-mainline during the USB device driver developement. Because of the interface
+mainline during the USB device driver development. Because of the interface
similarities the change to using mainline version will be trivial.
ILdummy network module
@@ -1922,7 +1922,7 @@
Here is an example implementation of this function:
-[red]#TODO: check mixing my_driver and ne2k, concider more schematic description#
+[red]#TODO: check mixing my_driver and ne2k, consider more schematic description#
[source,c]
-----------------
static int mydriver_add_device(ddf_dev_t *dev)
@@ -2008,7 +2008,7 @@
If you want to pass the packet data as they are, the memory holding them must
be prepared - locked. The function $dma_lock()$ does this for you - it forces
-physical location of the memory and prohibits any swaping out until you call
+physical location of the memory and prohibits any swapping out until you call
$dma_unlock()$. For easy use on packets there are functions
$nic_dma_lock_packet()$ and $nic_dma_unlock_packet()$.
@@ -2018,7 +2018,7 @@
using $register_interrupt_handler()$ function. You should do this in the
$add_device()$ function. The exact way how interrupts are handled in HelenOS
and the pseudo-code instructions are out of scope of this document - see
-{lt-thesis}[Lenka Trochtova's thesis] (in czech) for details. So, add this
+{lt-thesis}[Lenka Trochtova's thesis] (in Czech) for details. So, add this
piece of code into the $add_device()$ function after initializing the device.
[source,c]
@@ -2108,7 +2108,7 @@
^^^^^^^
Most network interface cards are able to limit the set of accepted frames,
these do not receive each frame that is detected on the link medium. The
-default behaviour is defined as receiving only frames with destination adress
+default behaviour is defined as receiving only frames with destination address
equal to NIC's MAC address, and broadcast frames (all without any restrictions
on VLAN tags). NICF defines handlers $on_unicast_mode_change()$,
$on_multicast_mode_change()$, $on_broadcast_mode_change()$,
@@ -2152,7 +2152,7 @@
Debugging compilation
^^^^^^^^^^^^^^^^^^^^^
-During the developement it is recommended to build both *+libnic+* and your
+During the development it is recommended to build both *+libnic+* and your
driver with debug-level logging enabled during development. This is done using
line
@@ -2175,9 +2175,9 @@
using HelenOS networking infrastructure present in the HelenOS before the
project has stared or new application implemented during the project.
-As all of the develped controllers are emulated by QEMU, the QEMU usage will be
+As all of the developed controllers are emulated by QEMU, the QEMU usage will be
described. The default configuration in the source tree is prepared for usage
-withing QEMU. The examples will be provided on rtl8139 controller, it's
+with QEMU. The examples will be provided on rtl8139 controller, it's
interface name in QEMU is pci03.
Nicconf
@@ -2196,7 +2196,7 @@
that default configuration for the controller can be used - the ip as the IL
and eth as NIL layer.
-In QEMU, -net user settign should be used. To provide rtl8139 testing in QEMU,
+In QEMU, -net user setting should be used. To provide rtl8139 testing in QEMU,
compile the HelenOS for ia32 or amd64 and run
[source, bash]
@@ -2211,8 +2211,8 @@
-------------
to ping default gateway created by QEMU. The disadvantage of this way is
-dependency on nontrivial ip layer functionality and ARP protocol implementation,
-only basic sending and receiving can be tested. Testing on real hardwar is also
+dependency on non-trivial ip layer functionality and ARP protocol implementation,
+only basic sending and receiving can be tested. Testing on real hardware is also
possible, only need is that other side answers ECHO requests correctly.
[[nictest_tests]]
@@ -2220,9 +2220,9 @@
~~~~~~~
Aside from simple ping to the gateway, the application <<nictest,nictest>>
-was developed to provide advanced tests of the controller functinality by both
+was developed to provide advanced tests of the controller functionality by both
interactive and automatic testing. The disadvantage of this kind of testing is
-necessarity of the second nictest instance on the other side of network.
+necessity of the second nictest instance on the other side of network.
Configuration
^^^^^^^^^^^^^
@@ -2248,7 +2248,7 @@
footnote:[http://trac.helenos.org/wiki/NetworkBridging]
For qemu-qemu testing, run two instances of qemu connected by QEMU socket
-networking. For the propper functionality the each instance must have different
+networking. For the proper functionality the each instance must have different
MAC address assigned
[source,bash]
@@ -2261,8 +2261,8 @@
-net socket,connect=:1234 -cdrom image.iso
---------
-NOTE: there is no necessarity for running the same controller on both instances,
-better attitude for testing is usisng some controller with already tested driver
+NOTE: there is no necessity for running the same controller on both instances,
+better attitude for testing is using some controller with already tested driver
on one side and the new controller on the other side.
Running tests
@@ -2333,15 +2333,15 @@
User documentation
------------------
The HelNet project improved the networking capabilities of the HelenOS operating
-system by implementation of the framework for NIC controller developement, DMA
+system by implementation of the framework for NIC controller development, DMA
support for the devices and NIC related staff.
Supported platforms
~~~~~~~~~~~~~~~~~~~
-The HelenOS subsistems developed by the HelNet project are supported on IA-32 and
+The HelenOS subsystems developed by the HelNet project are supported on IA-32 and
AMD-64 platform, running in *QEMU* emulator footnote:[http://qemu.org] or on the
real hardware. The supported network interface controllers are *RTL8139* in all
-versions and 8254x family of *Itel E1000* network interface controller.
+versions and 8254x family of *Intel E1000* network interface controller.
CDROM content
~~~~~~~~~~~~~
@@ -2353,7 +2353,7 @@
| %README% | The README file
| %helnet.pdf% | The electronic version of this documentation
| %html/% | Doxygen cross reference root directory
-| %html/index.html% | Doxygen cross referece main file
+| %html/index.html% | Doxygen cross reference main file
| %img/image_ia32_ip.iso% | IA32 cdrom image for QEMU, *ip* as the IL module
| %img/image_ia32_ildummy.iso% | IA32 cdrom image for QEMU, *ildummy* as the IL module
| %img/image_amd64_ip.iso% | AMD64 cdrom image for QEMU, *ip* as the IL module
@@ -2419,11 +2419,11 @@
make
-------------
from the root source directory. Select +amd64+ or +ia32+ from the +Load
-preconfigurated defaults+ menu, disable +Support for SMP+, change the settings
+preconfigured defaults+ menu, disable +Support for SMP+, change the settings
specific to target computer and press +Done+ to confirm the settings.
NOTE: The SMP support can remain enabled but the controller will be functional
-only with *software period* polling mode in multiprocessor enviroment due the
+only with *software period* polling mode in multiprocessor environment due the
bug in the APIC controller driver.
@@ -2464,7 +2464,7 @@
-------
to obtain list of available network interface. The nicconf help can be invoked
-by +nicconf -h+ order, detailed desciption including all arguments is in
+by +nicconf -h+ order, detailed description including all arguments is in
<<nicconf>>.
Nictest
@@ -2482,7 +2482,7 @@
More drivers
~~~~~~~~~~~~
Having full scale of NIC drivers as in other operating systems would be very
-nice. The two well-developped drivers provided within this project enable
+nice. The two well-developed drivers provided within this project enable
further development of HelenOS's networking abilities and also may serve as
reference implementations of drivers.
Drivers for other NICs should come upon the necessity to control hardware where
@@ -2491,13 +2491,13 @@
DMA framework future development
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
DMA framework is functional on IA32 and AMD64. But in can be extended to other
-platforms supported by HelenOS. Next DMA improvement is realted to AGP/PCI-X
+platforms supported by HelenOS. Next DMA improvement is related to AGP/PCI-X
support adding. These technologies can enable pseudoIOMMU operations, which
can translate bus address to physical memory address. Today is bus address
same as physical memory address. But support of this feature is above requests
to this project.
-Another possibility of developement can be implementation of drivers of
+Another possibility of development can be implementation of drivers of
busmaster devices. These devices are not required on modern Intel architecture
systems, but some other systems could require them.
@@ -2698,7 +2698,7 @@
|================================
| Interface callback | Requirements
| $wol_virtue_add$ | setting $on_wol_virtue_add()$ callback by $nic_set_wol_virtue_change_handlers()$ +
- propper setting and updating of maximal WoL capabilities by $nic_set_wol_max_caps()$
+ proper setting and updating of maximal WoL capabilities by $nic_set_wol_max_caps()$
| $wol_virtue_remove$ | setting $on_wol_virtue_remove()$ callback by $nic_set_wol_virtue_change_handlers()$
| $wol_virtue_probe$ | using default $wol_virtue_add()$ and $wol_virtue_remove()$ handlers
| $wol_virtue_list$ | using default $wol_virtue_add()$ and $wol_virtue_remove()$ handlers
@@ -2724,13 +2724,13 @@
ping functional. +
DMA allocator allocates memory with requested size,
added direct_backend.
-| 10th February 2011 | Oficial project start
-| March 2011 | Automatical address space searching in DMA framework,
- NICF driver lifecycle defined, E1000 demostrator is able
+| 10Th February 2011 | Official project start
+| March 2011 | Automatic address space searching in DMA framework,
+ NICF driver lifecycle defined, E1000 demonstrator is able
to receive packet. +
Full packet reception on RTL8139, autonegotiation,
filtering work started
-| April 2011 | Scather/gather memory page locking designed.
+| April 2011 | Scatter/gather memory page locking designed.
Near-to-final version of NIC interface. +
RTL8139 filtering finished.
E1000 is transmitting an receiving multiple packets.
@@ -2747,6 +2747,6 @@
Real hardware tests, designed DMA controller interface. +
VLAN support in E1000 driver. +
Documentation finished.
-| 1st September 2011 | Project delivered
+| 1St September 2011 | Project delivered
|======================
