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:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>