Re: RE:Thread model for NDIS driver -- What's your opinion?

Option 2 is the now totally deprecated original NT ‘miniport’ model (e.g.
scsiport and the early pre Mp ndis.) Discarded for good reasons: performance
on modern systems is generally horrible, especially for network miniports.

Mark Roddy

On Thu, Aug 4, 2011 at 5:06 PM, Jeffrey Tippet > wrote:

> Peter is right (of course) about option 3 being the “natural” model for NT
> drivers. And option 1 is very unnatural – you’ll spend a lot of time
> fighting the system if you go that route. (Even in your short description,
> you mentioned worrying about thread priority – you’ve already begun
> fighting the system’s design!)
> But option 2 isn’t terrible. Especially if you’re new to writing
> multithreaded code, or if you need to hammer out a reliable driver in a
> hurry, there are worse things you can do than have one giant lock. You’ll
> never have the fastest or most responsive driver, and you still won’t be
> exempt from needing careful design and thought. But it’s better to ship a
> slow and safe driver than to ship a big mess of erratic race conditions.
> It’s worth noting that early versions of NDIS forced you into a model like
> option 2. Those ancient serialized miniports can still run on Win7 today,
> and an end-user won’t really notice, as long as they don’t try to push more
> than 100Mpbs.
> So if you have the time and motivation to learn to write drivers properly,
> and you’re willing to tolerate a few buggy “teachable moments” along the
> way, then go with option 3. But if you just need to hammer out a driver
> quickly and move on with your life, option 2 will get you the most reliable
> driver in the shortest amount of time.
> —
> NTDEV is sponsored by OSR
> For our schedule of WDF, WDM, debugging and other seminars visit:
> To unsubscribe, visit the List Server section of OSR Online at