Hi,
I need to implement a mechanism for kernel to user communication (during the execution of a binary on windows), and I am confused b/w the two possible approaches:
- IOCTL based method (ie Inverted Call method)
- Mini filter port based communication method
Also mine is a legacy driver as of now but soon we are planning to port it to mini-filter and hence the approach that I choose today must be mini-filter friendly, which I am assuming both of these approaches are.
Also if I choose the port based communication method, is it mandatory for me to register as a mini-filter? If yes, are there are any side-effects? This is because today my driver is legacy.
I realize that some part of my question has already been asked in this forum but I am not able to find the exact answer that would help me choose b/w these 2 approaches.
Thanks,
Anshul Malik
Hi All,
Would really appreciate if someone can answer my question above.
Thanks in advance.
Anshul Malik
I would say the best mechanism for a mini-filter is the communication port,
but unfortunately that only works for mini-filters. While IOCTL’s can work
for both it is not the best approach.
I would create a user space API in a DLL that reflects a model which car
work for either mechanism, then when you upgrade from legacy to a
mini-filter replace the initial DLL that supports IOCTL’s with a new one
that supports communication ports.
Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Malik, Anshul
Sent: Wednesday, April 29, 2015 1:48 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] kernel <–> user communication
Hi,
I need to implement a mechanism for kernel to user communication (during the
execution of a binary on windows), and I am confused b/w the two possible
approaches:
- IOCTL based method (ie Inverted Call method) 2. Mini filter port based
communication method
Also mine is a legacy driver as of now but soon we are planning to port it
to mini-filter and hence the approach that I choose today must be
mini-filter friendly, which I am assuming both of these approaches are.
Also if I choose the port based communication method, is it mandatory for me
to register as a mini-filter? If yes, are there are any side-effects? This
is because today my driver is legacy.
I realize that some part of my question has already been asked in this forum
but I am not able to find the exact answer that would help me choose b/w
these 2 approaches.
Thanks,
Anshul Malik
NTFSD is sponsored by OSR
OSR is hiring!! Info at http://www.osr.com/careers
For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
>1. IOCTL based method (ie Inverted Call method)
- Mini filter port based communication method
- is internally 1), just with all plumbing already done for you.
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com
Thanks Don and Maxim.
The other part of my question is: If i register my legacy driver as a mini-filter too (so that i can take advantage of the comm port method) , which i guess is allowed, will there be nay side effects of doing this?
Thanks in advance.
Anshul Malik
I would suggest another approach, which from my experiments is the fastest way to communicate both kernel and user mode, but unfortunately is undocumented and you have to dig a little bit to get it working, and that is LPC.
Don’t know what other people here think about this, and since it is undocumented I don’t know if you want to go this way.
Well the one book that documented LPC, had samples that worked on one system
and not the next. When it did work, change the hardware it could fail, run
windows update it could fail. Perhaps with one of the research source
copies of Windows, one can derive the magic, but I would never use LPC in a
production system till Microsoft documented it.
Also, is it the fastest? I’ve gotten 1,200,000 IOCTL’s per second on a 2
core system, by using FastIo and planning well.
Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Thursday, April 30, 2015 5:58 AM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] kernel <–> user communication
I would suggest another approach, which from my experiments is the fastest
way to communicate both kernel and user mode, but unfortunately is
undocumented and you have to dig a little bit to get it working, and that is
LPC.
Don’t know what other people here think about this, and since it is
undocumented I don’t know if you want to go this way.
NTFSD is sponsored by OSR
OSR is hiring!! Info at http://www.osr.com/careers
For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Nice ! There you go.
I guess LPC is a more direct way to make the driver the “client” and the user-mode process the “server” and call directly to user-mode, but IOCTL can of course also work and it is the way to go.
No i can’t use something that is undocumented.
The next question is:
If i register my legacy driver as a mini-filter too (so that i can take advantage of the comm port method) , which i guess is allowed, will there be any side effects of doing this?
Not any that I can think of, unless you think you need to a really early boot driver, that needs a service load order earlier than FSFilter Infrastructure.
Ok then i’ll try registering my legacy driver as a mini-filter as well and let you know if i face any issue. Thanks for the help everyone.
Anshul Malik
This has been working fine so far.
Thanks everyone for the help !!!