Hello,
I have seen this msdn article:
http://msdn.microsoft.com/en-us/library/windows/hardware/ff539277(v=vs.85).aspx
I need a very fast / efficient method to transfer data from a user mode app to a NDIS driver.
Can the method above be used for this? Or is it for other kind of drivers?
Also, I have heard WMI also has some km-um communication. Can a NDIS driver use a WMI, or WMI implies a different kind of driver?
Thanks!
Or perhaps, can there be a socket-oriented approach for the km-um communication?
i.e. the NDIS driver to use some kernel mode socket and the user app to use some form of socket as well.
You can use standard Win32 asynchronous I/O fairly efficiently.
Your user-mode application would use I/O completion ports for handling UM
asynchronous I/O.
To achieve efficiency it is important to minimize user-mode/kernel-mode
transitions/transactions as much as possible. There is an indeterminate
latency involved in each transition in each direction and this latency is
mostly independent of the amount of data being transferred; that is:
transferring one byte in a transaction takes about the same time as
transferring 64Kb.
In addition, it would be important to have multiple concurrent asynchronous
I/O operations in progress at all times.
It might be possible to use named pipes as well.
Hope this makes some sense.
Good luck!
Thomas F. Divine
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
Sent: Friday, September 27, 2013 4:57 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Can one use communication ports on NDIS for km-um
communication?
Or perhaps, can there be a socket-oriented approach for the km-um
communication?
i.e. the NDIS driver to use some kernel mode socket and the user app to use
some form of socket as well.
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other 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
You cannot use this method, since it is provided for file system filter
drivers only. One can achieve high speeds of communication with IOCTL’s
using OVERLAPPED I/O and completion ports or more advanced mechanisms (on
the latest versions of Windows). The latest NT Insider from the website
that hosts this list has an article on the inverted call this is the model
you need.
Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
Sent: Friday, September 27, 2013 4:52 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Can one use communication ports on NDIS for km-um
communication?
Hello,
I have seen this msdn article:
http://msdn.microsoft.com/en-us/library/windows/hardware/ff539277(v=vs.85%
29.aspx
I need a very fast / efficient method to transfer data from a user mode app
to a NDIS driver.
Can the method above be used for this? Or is it for other kind of drivers?
Also, I have heard WMI also has some km-um communication. Can a NDIS driver
use a WMI, or WMI implies a different kind of driver?
Thanks!
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other 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
What is your definition of fast and efficient? What size buffers are you looking yo move around?
Thx
d
Bent from my phone
From: xxxxx@yahoo.commailto:xxxxx
Sent: ?9/?27/?2013 1:52 AM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: [ntdev] Can one use communication ports on NDIS for km-um communication?
Hello,
I have seen this msdn article:
http://msdn.microsoft.com/en-us/library/windows/hardware/ff539277(v=vs.85).aspx
I need a very fast / efficient method to transfer data from a user mode app to a NDIS driver.
Can the method above be used for this? Or is it for other kind of drivers?
Also, I have heard WMI also has some km-um communication. Can a NDIS driver use a WMI, or WMI implies a different kind of driver?
Thanks!
—
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other 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</mailto:xxxxx></mailto:xxxxx>
xxxxx@yahoo.com wrote:
I need a very fast / efficient method to transfer data from a user mode app to a NDIS driver.
Can the method above be used for this? Or is it for other kind of drivers?
How will you find the driver? Do you have a file handle? If you have a
handle, you can’t do much better than an ioctl. I don’t know how that
plays in the NDIS world.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Is the NDIS driver something you are producing?
And what exactly do you mean by “NDIS Driver”? Is it an NDIS Miniport
driver for a NIC? An NDIS Protocol Driver? An NDIS Filter Driver?
Depending on what you mean by ‘data’ and ‘efficient’ you might consider two
basic (and quite different) approaches:
An NDIS Miniport can expose objects to WMI. If you can describe what you
are doing in terms of WMI operations supported on NDIS Miniports than maybe
this will work.
An NDIS Miniport can expose an control device object on which you can
accept any kind of I/O you wish. This might be a Control Device per NIC
or one global to the driver through which all adapters can be communicated
with.
There are other variations like having the Miniport use QI to exchange
function pointers with a filter driver in the stack which exposes device
interfaces or control devices.
Perhaps you can tell us a bit more about what the higher level problem you
are trying to solve?
Good Luck,
Dave Cattley
We don’t have anything like Linux netlink here in Windows.
Roll your own…
– pa
“We don’t have anything like Linux netlink here in Windows.”
Is the linux netlink better (faster / more efficient) than the methods available in windows?
If yes, can you tell me how & why it’s so? I’ve heard it’s a kind of socket-based IPC (userspace is handled as a socket; has something for the kernel part).
Is WinSock not something similar on the win kernel?
(http://msdn.microsoft.com/en-us/library/windows/hardware/ff571083(v=vs.85).aspx)
Otherwise, I imagine a functionality like netlink could be implemented in win by originating packets in kernel for the localhost, and handling packets from localhost port X as coming from the user-mode IPC channel.
> Is the linux netlink better (faster / more efficient) than the methods available in windows? If yes,
can you tell me how & why it’s so?
Are you trying to provoke yet another “Windows vs Linux” flame war or what???
I’ve heard it’s a kind of socket-based IPC (userspace is handled as a socket; has something
for the kernel part). Is WinSock not something similar on the win kernel?
(http://msdn.microsoft.com/en-us/library/windows/hardware/ff571083(v=vs.85).aspx)
Socket layer is nothing more than just an interface that address family provider may implement. The exact details of implementation depend on the purpose that the address family in question serves. Linux netlink sockets provide an interface to AF_NETLINK address family. The purpose of this family is to provide a generic way of communication the kernel and user space processes that may be used in place of IOCTLs.
Windows kernel sockets provide a simple way for the kernel-mode components to make use of AF_INET and AF_INET6 address families.
Hopefully by now you understand that there is no relationship between netlink sockets and Windows kernel sockets whatsoever - they serve totally different purposes…
Otherwise, I imagine a functionality like netlink could be implemented in win by originating packets
in kernel for the localhost, and handling packets from localhost port X as coming from the
user-mode IPC channel
Sure you can do it this way…exactly the same way you can fly from Paris to London via Tokyo. Whether it makes sense to do so is already another question. In your particular example you propose to involve both TCPIP and AFD into delivering data from the kernel to the UM application, which makes as much sense as a Tokyo leg of above mentioned journey…
Anton Bassov
On 20-Oct-2013 00:17, xxxxx@yahoo.com wrote:
“We don’t have anything like Linux netlink here in Windows.”
Is the linux netlink better (faster / more efficient) than the methods available in windows?
If yes, can you tell me how & why it’s so?
Because… Windows… is… not… Linux!
IPC solutions made for Windows may be not less efficient than in Linux.
But Linux is opensource. So one can easily find the source, discuss it,
hack, copy-paste, and so on.
Due to closed-source tradition of Windows ecosystem, Windows software
made by others is not available for you, and even not easy to locate.
You’ve already asked about reuse of IPC for another Windows component
(Flt…) and got negative answer.
I’ve heard it’s a kind of socket-based IPC (userspace is handled as a
socket; has something for the kernel part).
Is WinSock not something similar on the win kernel?
Yes, the kernel winsock is quite similar to usermode one; using it
for IPC should work very well for not-very-high bandwidth.
Of course, it has overhead. In your situation it also can create
dangerous dependency of lower-level (esp, kernel) layer
on higher-level (esp. usermode).
Regards,
– pa
If you really want your product to be broken/slowed down by the firewall software - then go on using 127.0.0.1 on Windows.
For any sane reliable Windows product, it is a no-no.
For method call remoting, use the things like COM or .NET Remoting, or the good old DCE RPC. This is by far simpler then message generation/parsing code you will need to write in other cases.
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com
“We don’t have anything like Linux netlink here in Windows.”
Is the linux netlink better (faster / more efficient) than the methods available in windows?
If yes, can you tell me how & why it’s so? I’ve heard it’s a kind of socket-based IPC (userspace is handled as a socket; has something for the kernel part).Is WinSock not something similar on the win kernel?
(http://msdn.microsoft.com/en-us/library/windows/hardware/ff571083(v=vs.85).aspx)Otherwise, I imagine a functionality like netlink could be implemented in win by originating packets in kernel for the localhost, and handling packets from localhost port X as coming from the user-mode IPC channel.
> But Linux is opensource. So one can easily find the source, discuss it,
hack, copy-paste, and so on.
…and only then discover that this particular solution is not a recommended one and is deprecated in the next kernel build.
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com
> If you really want your product to be broken/slowed down by the
firewall software - then go on using 127.0.0.1 on Windows.
For any sane reliable Windows product, it is a no-no.
For method call remoting, use the things like COM or .NET Remoting, or
the good old DCE RPC. This is by far simpler then message
generation/parsing code you will need to write in other cases.–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com> “We don’t have anything like Linux netlink here in Windows.”
>
> Is the linux netlink better (faster / more efficient) than the methods
> available in windows?
> If yes, can you tell me how & why it’s so? I’ve heard it’s a kind of
> socket-based IPC (userspace is handled as a socket; has something for
> the kernel part).
>
> Is WinSock not something similar on the win kernel?
> (http://msdn.microsoft.com/en-us/library/windows/hardware/ff571083(v=vs.85).aspx)
>
> Otherwise, I imagine a functionality like netlink could be implemented
> in win by originating packets in kernel for the localhost, and handling
> packets from localhost port X as coming from the user-mode IPC channel.
>
Sounds pretty grotesque. If you feel a desperate need to avoid fairly
mature technologies such as COM, you can get a copy of Reeves & Brain
/Windows System Programming/, where there’s a chapter on how to create RPC
targets.
Personally, if I had to pass information across a boundary, I might be
tempted to send XML-formatted text strings. Overhead to marshal and
unmarshal would be, in comparison to a CALL instruction, rather horrible,
so it depends on the data bandwidth you need. We solved this decades ago
in the LG and IDL systems we built at CMU around 1978/1979 (I designed the
basic ideas of the LG system, and Steve Hobbs did the initial
implementation; IDL was the outcome of several years’ experience in using
LG and represented a stongly-typed model, contrasting with LG’s untyped
model. I like to think of both of these as “XML done right”)
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer