As I know, a filter driver attaches to the top of the stack. I am writing a keyboard filter driver and should attach to lower end or in the middle of the stack.
But I am not sure how to do this. “IoAttachDeviceToDeviceStack” will attach to the top of the stack.
Please help me.
Filter drivers are registered on the “UpperFilter” or “LowerFilter” registry values of target device class hive. These values are multi-string values and the filter devices will have their “AddDevice” routine called in the order their names appear on this list. I’m assuming you know each filter device will usually attach their devices during this call to their “AddDevice” routine.
I hope that helps.
Regards.
Although, as it has already been mentioned in the previous post, there are “UpperFilter” and “LowerFilter” specifiers, you just cannot be sure that you are the top of the stack, above or below some particular filter driver XYZ, etc. What above mentioned specifiers relate to is your driver’'s position in respect to FDO. However, if you have, say, 2 upper filters X and Y, you cannot be sure about their positions in respect to one another.
Therefore, you have to eliminate your requirement, and write your code without any assumptions about the stack position of your driver…
Anton Bassov
There are a couple of slightly incorrect answers i want to clarify
- you can specify a filter as a device OR class filter. I have very rarely seen a class lower filter, it is almost always a device lower filter.
- WRT ordering, there is a definitive order amongst the groups, from lowest to highest: class lower filters, device lower filters, FDO, device upper filters, class upper filters. There is also ordering within the group, the filters will be added in the order they are listed in the multi SZ value. There are two caveats
a) this does not guarantee ordering after install as another installer may change the order
b) the INF syntax only allows for append (vs positional insertion)
There is also ordering within the group, the filters will be added in the order they are listed in the multi SZ value. There are two caveats
a) this does not guarantee ordering after install as another installer may change the order
b) the INF syntax only allows for append (vs positional insertion)
Actually, the OP’s question reminds me of the situation that was endemic to “not-so-conventional” drivers before the advent of the Patch Guard, i.e. everyone wanted to be the first one in a hooked call chain. The most “exciting” scenario occurred when they started fighting one another for their place in a call chain…
Anton Bassov
anton_bassov wrote:
Actually, the OP’s question reminds me of the situation that was endemic to “not-so-conventional” drivers before the advent of the Patch Guard, i.e. everyone wanted to be the first one in a hooked call chain. The most “exciting” scenario occurred when they started fighting one another for their place in a call chain…
Maybe, but I’ll wager the issue is much simpler: he wants to attach in
the middle of a keyboard stack on the fly and just doesn’t grasp the
stacking concept yet.
Actually it is exactly the question that has been asked on this forum many times from the beginning. I know I answered this one over 15 years ago. There were a ton, of I want to be at the top of the stack, and fewer but still large I want to be directly above the device.
Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com
There were a ton, of I want to be at the top of the stack, and fewer but still large I want to be directly above the device.
…and, finally, we had encountered the one about being in the middle of the stack as well. Therefore, now we have the full “collection”…
Anton Bassov
There is also ordering within the group, the filters will be added in the order they are listed in the multi SZ value
This ordering has always been a detail of implementation and not architecture.
Are you saying this is now a set architectural precept that people can count on to never change?
Because if so, that a big news… at least to me.
Peter
There is no way the implementation behind these values can change. It has been this way for so long that Microsoft would not be able to change it without breaking already deployed drivers.
d
Not doing things that break already deployed drivers, like for example redefining boolean fields into bitmasks? That sort of change?
Sorry, couldn’t help the mild snark. We just identified one such change that was whacking us in a recent, uh, ‘update’ of Win10. In general, and certainly compared to the competition, MSFT does do an excellent job maintaining backwards compatibility.
redefining boolean fields into bitmasks
Do say more. Please!
certainly compared to the competition
OMG… I did not fully appreciate the concept of “compatibility among versions” (or lack thereof) until I saw the number of breaking changes between, say, versions of RHEL.
And I was “pleased” to read, just the other day, that in Linux 5 non-GPL’ed LKMs won’t be able to use FP or SIMD instructions. I mean… seriously? Greg K-H (who’s been seen on this forum, but not in a while) thinks this is a reasonable idea. Really?
Meanwhile, useful, complex, hardware drivers that were written on NT V4 ran without change up through Windows 8 in most cases. Sometimes the backward compatibility thing can be tiresome (ask me about the function IoForwardAndCatchIrp someday… it’s still there, I’m sure)… but you’ve gotta be thankful for it in the long run.
Anyhow… clearly, I digress.
P
Peter,
You are raising , IMHO, two totally unrelated issues,i.e.backwards compatibility between the kernel drivers and the one of the userland packages. Surely the latter one is annoying as hell. For example, you may be unable to install a package ABC because your currently installed libraries don’t support the features that it requires, and updating these dependencies may break some currently installed package XYZ. In this respect Windows is, indeed, miles ahead, compared to Linux.
Concerning the latter one, this is just the question of “politics”, rather than something based upon the technical reasoning (although you may hear the arguments that maintaining backwards compatibility supposedly stifles the innovation). In actuality, you are just encouraged to push your driver up the tree, and make it accepted to the kernel, effectively eliminating any worries about the support - achieving this part will automatically ensure that your driver is maintained for the next 5 years .
And I was “pleased” to read, just the other day, that in Linux 5 non-GPL’ed LKMs won’t be able to use FP or SIMD instructions.
Well, non-GPL’ed LKMs have been historically severely restricted in what they can do. If you choose non-GPLed option, NUMEROUS functions and structures (i.e. the ones marked as EXPORT_SYMBOL_GPL) are going to be unavailable to your driver. There is nothing particularly new here
I mean… seriously? Greg K-H (who’s been seen on this forum, but not in a while) thinks this is a reasonable idea. Really?
I dunno, but let’s compare the general acceptance rate of Linux, and, say, FreeBSD. Taking into consideration that, as far as the technical side is concerned, the latter is vastly superior to the former, something tells me that such aggressive “encouragement” to use GPL may be, indeed, beneficial, at least as far as acceptance is concerned. The problem here is that permissive licenses eliminate your incentive to contribute to the project, in the first place
Anton Bassov
Good reply, Mr Bassov.
compatibility between the kernel drivers and the one of the userland packages
No, no… kernel drivers and kernel driver interfaces. Move from RHEL 6 to RHEL 7 and all of a sudden, interfaces are gone. Or parameters to existing interfaces are changed. Can you imagine “In 19H1 we’re going to add an additional parameter to MmMapLockedPageSpexifyCache”? Unthinkable in Windows… apparently everyday business in Linux.
In actuality, you are just encouraged to push your driver up the tree, and make it accepted to the kernel, effectively eliminating any worries about the support
I get that. But “the tree” can only be so big, right? And they only want certain things.
So, not really “in actuality”, right? More like “in theory”… what do you think the chances of The Powers That Be accepting a driver from OSR into The Tree? Like, you know, an encrypting file system? Zero. Less than zero.
One of the funniest stories I have on this topic was when a good friend of mine, who’s a very senior guy at MSFT, we’ll known and highly respected, tried to get the Linux people to accept one of his (entirely non controversial) fixes. He basically couldn’t get anyone to give him the time of day. They were like “Who the fuck are you?”
Don’t get me wrong. I don’t think they owed him anything. And if I were them, is would have said the same thing. They legit had no idea who he was. My point is “pushing it upstream” so that you don’t have to maintain it really isn’t an option for normal folks. It’s no more likely than a random guy getting his code accepted into the Windows kernel.
P
Peter_Viscarola_(OSR) wrote:
OMG… I did not fully appreciate the concept of “compatibility among versions” (or lack thereof) until I saw the number of breaking changes between, say, versions of RHEL.
At the kernel level, it’s true. It’s much less of a problem now than it
used to be in the 2.4/2.6 timeframe. However, it’s still true that a
kernel driver binary works with one kernel version.
It’s both a curse and a blessing. The churn does mean that bad ideas
can be tossed out, something that Windows simply cannot do. The legacy
burden is a heavy one, and Windows carries a chain it has forged
link-by-link over 30 years. I would not be surprised to hear that
Microsoft was ending Windows and starting over from scratch.
MacOS has the same problem even in user space. I’ve been surprised
several times when upgrades led to user-mode apps no longer working.
And I was “pleased” to read, just the other day, that in Linux 5 non-GPL’ed LKMs won’t be able to use FP or SIMD instructions. I mean… seriously? Greg K-H (who’s been seen on this forum, but not in a while) thinks this is a reasonable idea. Really?
Greg K-H is a very bright guy, but he is certainly a zealot for the GPL
religion. However, proposals like that don’t often make it into the
releases.
Meanwhile, useful, complex, hardware drivers that were written on NT V4 ran without change up through Windows 8 in most cases. Sometimes the backward compatibility thing can be tiresome (ask me about the function IoForwardAndCatchIrp someday… it’s still there, I’m sure)… but you’ve gotta be thankful for it in the long run.
Maybe. Would the world be better off if those authors had been forced
to address their problems? I think you know that NT4 drivers rarely
placed very high on the quality scale.
@“Peter_Viscarola_(OSR)” @Tim_Roberts
I have a question ? Can you help me How to run the Microsoft driver samples on the Vitual box? Because I buitl then run with the osr tool it shows an error “the service cannot be started either because it is disabled disabled”.
Good reply, Mr Bassov.
What about granting me another “lucky coin” - I had a temerity to use up the one I had…
[begin quote]
I get that. But “the tree” can only be so big, right? And they only want certain things.
So, not really “in actuality”, right? More like “in theory”… what do you think the chances of The Powers That Be accepting a driver from OSR into The Tree? Like, you know, an encrypting file system? Zero. Less than zero.
[end quote]
I think this is more of a question of a value that any given contribution may potentially add…
For example, let’s say you write a driver for a hardware device that is not yet supported by the kernel. The potential value of such contribution is self-evident - the larger the hardware base that the kernel supports, the better it is for the entire Linux community.
Therefore, the chance of your code getting accepted is quite high.
However, when it comes to software-only drivers like file systems, as well as rewrites of the currently existing workable drivers, the potential benefits are already not so obvious. For example, what are the features that your file system offers and all other file systems in the tree don’t? You have to give a pretty convincing answer to this question, and not only to yourself but to all other guys in the community.
Therefore, you would need to provide much stronger justification (I think HR/marketoid/etc types would call it USP, i.e. the unique selling point) in this case.
My point is “pushing it upstream” so that you don’t have to maintain it really isn’t an option for normal folks.
Fair enough - this is, indeed,not the easiest task in existence, and Linux kernel list does not seem to be particularly friendly to the “newbies” either. You may, indeed, hear quite a few unfair, rude and arrogant comments about your code. Therefore, you have to swallow your pride and just keep on going ahead,no matter what…
Anton Bassov
I have a question…
@betapcode Please start a new thread and ask your question, providing complete details. We’ll be happy to answer it.
The legacy burden is a heavy one, and Windows carries a chain it has forged link-by-link over 30 years.
Agreed. In class I describe this as the chain dragged along by Scrooge in A Christmas Carol.
I would not be surprised to hear that Microsoft was ending Windows and starting over from scratch.
That’s been tried and it didn’t fly. Seriously. It’s tough to make the business case to deliberately lose the entire installed base of applications and hardware. And the internal politics is the a real killer. What’s new has to have enough value to end users, who really “just want to get shit done.”
Still:
- It’s the type of thing that only MSFT… with its massive resources… could do. A really new generation OS, built with integral modern security and reliability concepts from the ground up… it would be a wonderful thing.
- When such a move was last contemplated at MSFT, the world wasn’t ready. Now, things are very different. A truly secure kernel, and an inherently secure app model, backed by Microsoft? It’d have to provide app-level compat (similar to Win 3.1 to NT had), but I think the world would welcome it.
- Is a general purpose OS for desktops, laptops, and servers still important in the long term?
- Maybe a “cleanup” release of Windows should be scheduled… either in the meantime or instead of a whole new OS. There’s so much stupid shit on that long chain of legacy… it’s time to heave out more of it. Every time I have to explain FILE_DEVICE_SECURE_OPEN I get nauseous. But that bit is yet another of my particular hot buttons.
Thread drift much?
Peter