Hello,
I want to create ARP request in NDIS 6.0 LWF’s Sendnetbufferlist
function. I am creating the ARP packet using MDL and then attaching it to a
new NDisBuffer and Ndisbufferlist. And then sending it to the miniport
driver.
So my question is do I need to use existing netbufferlists which is passed
from the protocol driver ,then how can i put it at the end or front of that
netbufferlist.(or my approach of creating a new buffer list is good?).
I am getting an exception pacer.sys (Interrupt level is to high to access
the buffer) when I tried to create my netbufferlists.
On 4/6/07, Don Burn wrote:
>
>
> “Mike Kemp” wrote in message news:xxxxx@ntdev…
> > Hi Peter
> >
> > I’d appreciate your comments: When I had to develop a driver last year I
> > wanted to wait for WDF but in the end had to do it with ordinary DDK as
> > WDF wasn’t available when I started.
> >
> > That meant I had to learn the basic DDK tricks, i.e. raw kernel
> > programming.
> >
> > The question is whether anyone starting now can start with WDF without
> > needing to know the detail underneath it, or if they’ll still need to
> > know how to write a non WDF driver.
> >
> > It’s a question about whether it’s really:
> >
> > (a) like MFC, which although useful, it turned out (when I learnt to
> > program Windows apps inthe 90’s) that you still had to know what was
> > going on underneath, or
> >
> > (b) like C etc, which successfully completely wraps the machine
> > underneath so you don’t need to know how it works at assembler level
> > (except when the compiler generates garbage code which is thankfully
> rare
> > these days).
> >
> > So in other words, should someone new wait for the WDF books we hear are
> > almost ready, or is Oney still a pre-requisite.
> >
> > Thanks for you insight on this
> >
> > Mike
>
> Mike,
>
> My view is the answer is a little of both. It is like MFC in that
> you
> can dive under it and for many things what you are seeing is the
> underlying
> model, for instance you will still see IRP’s, but how you access them and
> queue them is different.
>
> Where it is like C is that PnP and Power which used to be this horrid
> state machine you needed to create, typically one would start with an
> existing one and then try to adapt it to the current machine and “fix it”,
> has been abstracted to a well designed set of calls. IIRC the WDK team
> found that a complete state machine for this was on the order of 300
> states, but the typical support for PnP and Power in a KMDF driver is
> roughly half a dozen short routines or less.
>
> I have a lot of experience with legacy and WDM drivers, but knowing
> the pain of PnP/Power I will not do another if at all possible even though
> I still struggle with learning / getting used to the new model. Of course
> maybe I should not call it the new model, since Microsoft started asking
> for input from developers at WinHEC 5 years ago this month.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
> Remove StopSpam to reply
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
–
Thanks
Abhijeet Kolekar