cvs commit: src/sys/compat/ndis subr_ndis.c subr_ntoskrnl.c

[Doug Rabson]

I think the difference between Jan 1 1601 and Jan 1 1970 is 11644473600
seconds. Thats the conversion factor I have in my cross-platform game
engine code anyway.

On Fri, 2003-12-12 at 22:35, Bill Paul wrote:
> wpaul       2003/12/12 14:35:13 PST
> 
>   FreeBSD src repository
> 
>   Modified files:
>     sys/compat/ndis      subr_ndis.c subr_ntoskrnl.c 
>   Log:
>   Implement some more NDIS and ntoskrnl API calls:
>   
>   subr_ndis.c: NdisGetCurrentSystemTime() which, according to the
>   Microsoft documentation returns "the number of 100 nanosecond
>   intervals since January 1, 1601." I have no idea what's so special
>   about that epoch or why they chose 100 nanosecond ticks. I don't
>   know the proper offset to convert nanotime() from the UNIX epoch
>   to January 1, 1601, so for now I'm just doing the unit convertion
>   to 100s of nanoseconds.
>   
>   subr_ntoskrnl.c: memcpy(), memset(), ExInterlockedPopEntrySList(),
>   ExInterlockedPushEntrySList().
>   
>   The latter two are different from InterlockedPopEntrySList()
>   and InterlockedPushEntrySList() in that they accept a spinlock to
>   hold while executing, whereas the non-Ex routines use a lock
>   internal to ntoskrnl. I also modified ExInitializePagedLookasideList()
>   and ExInitializeNPagedLookasideList() to initialize mutex locks
>   within the lookaside structures. It seems that in NDIS 5.0,
>   the lookaside allocate/free routines ExInterlockedPopEntrySList()
>   and ExInterlockedPushEntrySList(), which require the use of the
>   per-lookaside spinlock, whereas in NDIS 5.1, the per-lookaside
>   spinlock is deprecated. We need to support both cases.
>   
>   Note that I appear to be doing something wrong with
>   ExInterlockedPopEntrySList() and ExInterlockedPushEntrySList():
>   they don't appear to obtain proper pointers to their arguments,
>   so I'm probably doing something wrong in terms of their calling
>   convention (they're declared to be FASTCALL in Widnows, and I'm
>   not sure what that means for gcc). It happens that in my stub
>   lookaside implementation, they don't need to do any work anyway,
>   so for now I've hacked them to always return NULL, which avoids
>   corrupting the stack. I need to do this right though.
>   
>   Revision  Changes    Path
>   1.3       +17 -0     src/sys/compat/ndis/subr_ndis.c
>   1.2       +62 -0     src/sys/compat/ndis/subr_ntoskrnl.c