ndis: spelling fixes in comments.
No functional change.
This commit is contained in:
parent
5f7f519b76
commit
2824fbf0a8
@ -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,
|
||||
|
@ -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;
|
||||
|
@ -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
|
||||
|
@ -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.
|
||||
*
|
||||
|
@ -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)
|
||||
|
@ -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,
|
||||
|
Loading…
Reference in New Issue
Block a user