ndis: spelling fixes in comments.

No functional change.
This commit is contained in:
Pedro F. Giffuni 2016-04-30 00:35:46 +00:00
parent 2bede1b82a
commit 72ffecf147
Notes: svn2git 2020-12-20 02:59:44 +00:00
svn path=/head/; revision=298828
6 changed files with 10 additions and 10 deletions

View File

@ -717,7 +717,7 @@ ndis_ptom(m0, p)
* send routine.
*
* NDIS packets consist of two parts: an ndis_packet structure,
* which is vaguely analagous to the pkthdr portion of an mbuf,
* which is vaguely analogous to the pkthdr portion of an mbuf,
* and one or more ndis_buffer structures, which define the
* actual memory segments in which the packet data resides.
* We need to allocate one ndis_buffer for each mbuf in a chain,

View File

@ -1042,7 +1042,7 @@ struct ndis_request {
uint32_t nr_bytesneeded;
} ndis_set_information;
} ndis_data;
/* NDIS 5.0 extentions */
/* NDIS 5.0 extensions */
uint8_t nr_ndis_rsvd[9 * sizeof(void *)];
union {
uint8_t nr_callmgr_rsvd[2 * sizeof(void *)];
@ -1444,7 +1444,7 @@ struct ndis_miniport_characteristics {
void * nmc_setinfo_func;
void * nmc_transferdata_func;
/* NDIS 4.0 extentions */
/* NDIS 4.0 extensions */
void * nmc_return_packet_func;
void * nmc_sendmulti_func;
@ -1459,7 +1459,7 @@ struct ndis_miniport_characteristics {
void * nmc_comultisend_func;
void * nmc_corequest_func;
/* NDIS 5.1 extentions */
/* NDIS 5.1 extensions */
void * nmc_canceltxpkts_handler;
void * nmc_pnpevent_handler;

View File

@ -670,13 +670,13 @@ struct kuser_shared_data {
* created and maintained by bus drivers. For example, the PCI
* bus driver might detect two PCI ethernet cards on a given
* bus. The PCI bus driver will then allocate two device_objects
* for its own internal bookeeping purposes. This is analagous
* for its own internal bookeeping purposes. This is analogous
* to the device_t that the FreeBSD PCI code allocates and passes
* into each PCI driver's probe and attach routines.
*
* When an ethernet driver claims one of the ethernet cards
* on the bus, it will create its own device_object. This is
* the Functional Device Object. This object is analagous to the
* the Functional Device Object. This object is analogous to the
* device-specific softc structure.
*/
@ -962,7 +962,7 @@ struct io_stack_location {
/*
* There's a big-ass union here in the actual Windows
* definition of the stucture, but it contains stuff
* definition of the structure, but it contains stuff
* that doesn't really apply to BSD, and defining it
* all properly would require duplicating over a dozen
* other structures that we'll never use. Since the

View File

@ -274,7 +274,7 @@ READ_PORT_BUFFER_UCHAR(port, val, cnt)
* KeAcquireSpinLock() and KeReleaseSpinLock(), but these are just
* macros that call KfAcquireSpinLock() and KfReleaseSpinLock().
* KefAcquireSpinLockAtDpcLevel() and KefReleaseSpinLockFromDpcLevel()
* perform the lock aquisition/release functions without doing the
* perform the lock acquisition/release functions without doing the
* IRQL manipulation, and are used when one is already running at
* DISPATCH_LEVEL. Make sense? Good.
*

View File

@ -722,7 +722,7 @@ IoGetDriverObjectExtension(drv, clid)
/*
* Sanity check. Our dummy bus drivers don't have
* any driver extentions.
* any driver extensions.
*/
if (drv->dro_driverext == NULL)

View File

@ -36,7 +36,7 @@ __FBSDID("$FreeBSD$");
/*
* This file contains routines for relocating and dynamically linking
* executable object code files in the Windows(r) PE (Portable Executable)
* format. In Windows, anything with a .EXE, .DLL or .SYS extention is
* format. In Windows, anything with a .EXE, .DLL or .SYS extension is
* considered an executable, and all such files have some structures in
* common. The PE format was apparently based largely on COFF but has
* mutated significantly over time. We are mainly concerned with .SYS files,