Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

WDF spinlocks, and WDM

Jamey_KirbyJamey_Kirby Member - All Emails Posts: 429
So, I'm all stoked now that my port is moving along. Now I need to port the linked list. I would expect there to be WDF equivalents to the interlocked linked list APIs that are all tidy and use the WDFSPINLOCK. No such APIs. So if I use my current list code, I'll have to sprinkle some WDM spinlock code around my driver. Is this a good idea in general?

Is there another synchronization object that I should be using?

Is this where custom object types come into play? Maybe create a custom object type for the elements and put them in a WDF collection? Is that an example of how custom object types might be used?

So much to learn, so little time.

-- Jamey

Comments

  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,434
    If it works, keep it. The wdf abstracts where it adds value, there is nothing in the interlocked list space that wdf could have added. A wdfcollection is going to be slower and require an allocation per added object, probably too much overhead for what you want.

    Bent from my phone
    ________________________________
    From: xxxxx@lists.osr.com on behalf of xxxxx@gmail.com
    Sent: Monday, March 19, 2018 7:53:09 PM
    To: Windows System Software Devs Interest List
    Subject: [ntdev] WDF spinlocks, and WDM

    So, I'm all stoked now that my port is moving along. Now I need to port the linked list. I would expect there to be WDF equivalents to the interlocked linked list APIs that are all tidy and use the WDFSPINLOCK. No such APIs. So if I use my current list code, I'll have to sprinkle some WDM spinlock code around my driver. Is this a good idea in general?

    Is there another synchronization object that I should be using?

    Is this where custom object types come into play? Maybe create a custom object type for the elements and put them in a WDF collection? Is that an example of how custom object types might be used?

    So much to learn, so little time.

    -- Jamey

    ---
    NTDEV is sponsored by OSR

    Visit the list online at:

    MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
    Details at

    To unsubscribe, visit the List Server section of OSR Online at
    d
  • Jamey_KirbyJamey_Kirby Member - All Emails Posts: 429
    Thanks.

    I started looking at general objects, and that would do exactly what i want with using a collection, but I too was concerned about the performance of the collection. In my current list, I have a driver global lookaside list (Which I did WDFify) for my list elements, and it is quite efficient.
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,223
    <quote>
    WDF abstracts where it adds value
    </quote>

    See... THIS is precisely the beauty of WDF.

    Use WDF where it adds value... and that is a LOT of places -- But not everywhere; Drop down to WDM where that best fits your needs.

    In 10+ years of using WDF, I've been *very* pleased with it... with a few limited exceptions. I *really* wish MSFT would do a WDF V2 to advance things a bit, and smooth out some of the rougher edges, but I'm pretty good with what we have.

    I'm glad you're into it Jamey... I think you'll be pleased you're putting in the effort. There is little that's as cool as being able to whip-up a WDF filter driver in, like, ten minutes.

    Peter
    OSR
    @OSRDrivers

    Peter Viscarola
    OSR
    @OSRDrivers

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 12,980
    xxxxx@osr.com wrote:
    > In 10+ years of using WDF, I've been *very* pleased with it... with a few limited exceptions. I *really* wish MSFT would do a WDF V2 to advance things a bit, and smooth out some of the rougher edges, but I'm pretty good with what we have.

    Yes.  In MY view, the biggest gap in WDF coverage, as Jamey discovered,
    is the lack of containers.  I have become so spoiled by the ubiquity of
    STL that I desperately miss them in kernel code.  All we really have are
    WDFQUEUE and WDFCOLLECTION, and neither one of them will win any awards
    for "ease of use".  A WDFQUEUE is strongly tied to WDFREQUEST, it is
    essentially impossible to enumerate through a WDFQUEUE without bringing
    up the sample in the documentation, the use of a dummy/proxy object is
    certainly non-intuitive, and the searching offered by
    WdfIoQueueFindRequest is weirdly specific to one single task.  A
    WDFCOLLECTION is more general, but it can only grow on one end, and
    there's no searching primitive at all.

    An STL subset with nothing more than std::vector and std::list, with a
    few algorithms and some interlocked searching primitives based on
    lambdas would allow us to use known good data structures without having
    to reinvent and readapt them every time.  The built-in compiler support
    for iterating through them would work just fine.

    --
    Tim Roberts, xxxxx@probo.com
    Providenza & Boekelheide, Inc.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Jamey_KirbyJamey_Kirby Member - All Emails Posts: 429
    Thanks for the advice. I'll stop trying to push everything into a round
    hole, and just use WDF where it seems appropriate.

    Here is my write handler. Look ok?

    VOID FilterEvtRequestWriteComplete(WDFREQUEST Request, WDFIOTARGET Target,
    PWDF_REQUEST_COMPLETION_PARAMS Params, WDFCONTEXT Context) {
    NTSTATUS Status = WdfRequestGetStatus(Request);
    ULONG_PTR Information = WdfRequestGetInformation(Request);

    if (NT_SUCCESS(Status) && Information != 0) {
    #pragma warning(push) // Save warning state.
    #pragma warning(disable:4456) // Enable shadowing.
    NTSTATUS Status;
    WDFMEMORY MemoryHandle;
    Status = WdfMemoryCreateFromLookaside(g_WriteEntryLookaside, &MemoryHandle);
    if (NT_SUCCESS(Status)) {
    PWRITE_ENTRY WriteEntry = WdfMemoryGetBuffer(MemoryHandle, NULL);
    WriteEntry->Offset = Params->Parameters.Write.Offset;

    // Should be the same?
    // WriteEntry->Length = Params->IoStatus.Information;
    WriteEntry->Length = Information;

    PFILTER_CONTEXT FilterContext =
    GetFilterContext(WdfIoQueueGetDevice(WdfRequestGetIoQueue(Request)));
    ExInterlockedInsertTailList(&FilterContext->WriteListHead,
    &WriteEntry->Entry, &FilterContext->WriteListLock);
    }
    #pragma warning(pop) // Restore warning state.
    }

    WdfRequestCompleteWithInformation(Request, Status, Information);
    DBG_UNREFERENCED_PARAMETER(Target);
    DBG_UNREFERENCED_PARAMETER(Context);
    }

    VOID FilterEvtWrite(WDFQUEUE Queue, WDFREQUEST Request, size_t Length) {
    KdPrintEx((DPFLTR_IHVDRIVER_ID, DPFLTR_INFO_LEVEL,
    "FilterEvtWrite()\n"));
    WDFDEVICE FilterDevice = WdfIoQueueGetDevice(Queue);
    PFILTER_CONTEXT FilterContext = GetFilterContext(FilterDevice);
    WdfRequestFormatRequestUsingCurrentType(Request);
    WdfRequestSetCompletionRoutine(Request, FilterEvtRequestWriteComplete,
    NULL);
    WdfRequestSend(Request, WdfDeviceGetIoTarget(FilterDevice), NULL);
    DBG_UNREFERENCED_LOCAL_VARIABLE(FilterContext);
    DBG_UNREFERENCED_PARAMETER(Length);
    }


    On Tue, Mar 20, 2018 at 10:29 AM xxxxx@osr.com
    wrote:

    >
    > WDF abstracts where it adds value
    >
    >
    > See... THIS is precisely the beauty of WDF.
    >
    > Use WDF where it adds value... and that is a LOT of places -- But not
    > everywhere; Drop down to WDM where that best fits your needs.
    >
    > In 10+ years of using WDF, I've been *very* pleased with it... with a few
    > limited exceptions. I *really* wish MSFT would do a WDF V2 to advance
    > things a bit, and smooth out some of the rougher edges, but I'm pretty good
    > with what we have.
    >
    > I'm glad you're into it Jamey... I think you'll be pleased you're putting
    > in the effort. There is little that's as cool as being able to whip-up a
    > WDF filter driver in, like, ten minutes.
    >
    > Peter
    > OSR
    > @OSRDrivers
    >
    >
    >
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > Visit the list online at: <
    > http://www.osronline.com/showlists.cfm?list=ntdev>;
    >
    > MONTHLY seminars on crash dump analysis, WDF, Windows internals and
    > software drivers!
    > Details at
    >
    > To unsubscribe, visit the List Server section of OSR Online at <
    > http://www.osronline.com/page.cfm?name=ListServer>;
    >
  • Jamey_KirbyJamey_Kirby Member - All Emails Posts: 429
    The kernel APIs have all the nice algorithms for RB, Splay, and AVL trees.
    It should not be too difficult to wrap these in WDF. I've seen a couple of
    attempts to create a STL like subset for the kernel, but none that really
    shine.

    I will say that WDF makes some things much easier. I have removed a lot of
    synchronization stuff from my code; remove locks for example; WDF handles
    all of that for you.

    In my thread, I used to use KeWaitForMultipleObjects(), and then set an
    event somewhere else to trigger the thread. I am looking to see if WDF has
    any better abstractions. I am having fun doing the port, my client is
    pulling his hair out because I have extended my deadline :)



    On Tue, Mar 20, 2018 at 1:21 PM xxxxx@probo.com wrote:

    > xxxxx@osr.com wrote:
    > > In 10+ years of using WDF, I've been *very* pleased with it... with a
    > few limited exceptions. I *really* wish MSFT would do a WDF V2 to advance
    > things a bit, and smooth out some of the rougher edges, but I'm pretty good
    > with what we have.
    >
    > Yes. In MY view, the biggest gap in WDF coverage, as Jamey discovered,
    > is the lack of containers. I have become so spoiled by the ubiquity of
    > STL that I desperately miss them in kernel code. All we really have are
    > WDFQUEUE and WDFCOLLECTION, and neither one of them will win any awards
    > for "ease of use". A WDFQUEUE is strongly tied to WDFREQUEST, it is
    > essentially impossible to enumerate through a WDFQUEUE without bringing
    > up the sample in the documentation, the use of a dummy/proxy object is
    > certainly non-intuitive, and the searching offered by
    > WdfIoQueueFindRequest is weirdly specific to one single task. A
    > WDFCOLLECTION is more general, but it can only grow on one end, and
    > there's no searching primitive at all.
    >
    > An STL subset with nothing more than std::vector and std::list, with a
    > few algorithms and some interlocked searching primitives based on
    > lambdas would allow us to use known good data structures without having
    > to reinvent and readapt them every time. The built-in compiler support
    > for iterating through them would work just fine.
    >
    > --
    > Tim Roberts, xxxxx@probo.com
    > Providenza & Boekelheide, Inc.
    >
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > Visit the list online at: <
    > http://www.osronline.com/showlists.cfm?list=ntdev>;
    >
    > MONTHLY seminars on crash dump analysis, WDF, Windows internals and
    > software drivers!
    > Details at
    >
    > To unsubscribe, visit the List Server section of OSR Online at <
    > http://www.osronline.com/page.cfm?name=ListServer>;
    >
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,223
    <quote>
    In MY view, the biggest gap in WDF coverage, as Jamey discovered,
    is the lack of containers.
    </quote>

    Well... should that really be WDF, or should it be part of the underlying language support like STL?

    I would add to containers "string manipulation"... an unnecessary PITA.

    There are gaps in WDF for sure. Much about I/O Targets, for example, could use a ton of smoothing, and it could be easily done. Having no clear abstraction for passing things from your ISR to your DPC was something that, when KMDF was written, was a known thing... but with no obvious answer time sorta ran out. There's also, of course, the whole issue of better handling for cancel, which can still be SUPER painful.

    Peter
    OSR
    @OSRDrivers

    Peter Viscarola
    OSR
    @OSRDrivers

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
Developing Minifilters 29 July 2019 OSR Seminar Space
Writing WDF Drivers 23 Sept 2019 OSR Seminar Space
Kernel Debugging 21 Oct 2019 OSR Seminar Space
Internals & Software Drivers 18 Nov 2019 Dulles, VA