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

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: https:

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

To unsubscribe, visit the List Server section of OSR Online at https:</https:></https:></https:>

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.

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

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.

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:

>


>
> 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&gt;
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:>

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 :slight_smile:

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&gt;
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:>

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