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

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

A driver that targets a single CPU.

Michael_RolleMichael_Rolle Member - All Emails Posts: 135

I've been struggling with writing a driver that operates on only one CPU (because it involves per-CPU registers), but is able to service multiple user clients each on a different CPU.
I've been using a single Device for the driver, and having each open File on the device supply IOCTLs that grab and release one CPU at a time. But keeping track of which File has which CPU (if any) and synchronizing all of that is somewhat messy.
However, I got a bright idea which is to have a separate Device object with its own name and symbolic link for each CPU on the system. This way, the user code opens a File with the name corresponding to the desired CPU. The Devices are Exclusive access, so that handles possible collisions between different users.
The only difficulty I see is how to manage the names for all these Devices. Instead of a constant name like L"\Device\devMyDriver", I would have to append a digit, or possibly more digits, to indicate the CPU number. A Device will allocate a bunch of nonpaged pool but only while it is open for some user File. I presume that the overhead of having several Device Objects around is not a big problem as long as the Device Extension is pretty small.

I don't really have a question here, it's more to put this idea out to future developers. And if there's some reason anyone can see it would be a poor choice, please comment about that.

Comments

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 12,914
    via Email
    On Feb 17, 2019, at 12:00 AM, Michael_Rolle wrote:
    >
    > I've been using a single Device for the driver, and having each open File on the device supply IOCTLs that grab and release one CPU at a time. But keeping track of which File has which CPU (if any) and synchronizing all of that is somewhat messy.

    Is it? It doesn't seem like it should be very hard. You know that a user-mode app can lock itself into a CPU on its own, using SetThreadAffinityMask?


    > The only difficulty I see is how to manage the names for all these Devices. Instead of a constant name like L"\Device\devMyDriver", I would have to append a digit, or possibly more digits, to indicate the CPU number. A Device will allocate a bunch of nonpaged pool but only while it is open for some user File. I presume that the overhead of having several Device Objects around is not a big problem as long as the Device Extension is pretty small.

    Couldn't you use a single device object, and use the path info to select a CPU, like "\Device\devMyDriver\0"? That would let you do your own lock management at IRP_MJ_CREATE time.

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

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

  • Michael_RolleMichael_Rolle Member - All Emails Posts: 135

    Couldn't you use a single device object, and use the path info to select a CPU, like "\Device\devMyDriver\0"? That would let you do your own lock management at IRP_MJ_CREATE time.

    I didn't know I could do that. How would every "\Device\devMyDriver_n_" all get mapped to the same Device Object? I thought there was a 1-1 correspondence. Can I call IoCreateSymbolicLink with several symbolic names for the same internal name? And where does DispatchCreate find the path info?
    If I go this route, then the driver would just have to reject any DispatchCreate that uses the same symbolic name as an earlier DispatchCreate that hasn't yet been DispatchClose'd.
    Is the overhead of having more DeviceObjects, one for each n, significant?

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,138

    See this.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • Michael_RolleMichael_Rolle Member - All Emails Posts: 135

    Thanks for the link, Peter. It answers my question in my previous comment.
    If I understand this correctly, to use \Device\devMyDriver\0, the driver only creates \??\devMyDriver as a symbolic link to a single Device Object named \Device\devMyDriver. Then when the user creates a File called \\.\devMyCriver\0, my DispatchCreate routine (I'm using WDM, not WDF as your blog is oriented to) can get the File handle and from that get the \0 suffix.
    Since I'm not using WDF, WdfDeviceInitSetFileObjectConfig is not available. So I want to set a Context pointer in the File object in my DispatchCreate. Since I am not a FSD or anything like that, I assume I can store a pointer to some Context that I've allocated (nonpaged, of course) in the FILE_OBJECT's FsContext member.
    Please someone post about whether this is all correct (or not).

    For a future reader to benefit from my mistakes...
    I tried creating a separate Device for each suffix, with a name \Device\devMyDriver\0 and exclusive access. I got C0000024 from IoCreateDevice. I gather that it doesn't like that last \, and perhaps I need to create a Directory called \Device\devMyDriver first. I'm saying this for benefit of future people. For myself, I could as easily use \Device\devMyDriver-0, and a symlink \??\devMyDriver-0 That would easily take care of ensuring exclusive user access to each Device, and the Device Extension would serve in place of a File's Context. If the -0 suffix scheme doesn't work, I'll post that here.

    How do you experts learn about this stuff? Is it documented somewhere, or do you have inside contacts at Microsoft? Just sorry I couldn't find this info on my own.

  • Michael_RolleMichael_Rolle Member - All Emails Posts: 135

    No problem with -0 as a suffix for both the device name and the symbolic link. :)

  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,428
    via Email
    You have it all correct. The Filename will be
    d
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
Writing WDF Drivers 25 Feb 2019 OSR Seminar Space
Developing Minifilters 8 April 2019 OSR Seminar Space