Driver Problems? Questions? Issues?
Put OSR's experience to work for you! Contact us for assistance with:
  • Creating the right design for your requirements
  • Reviewing your existing driver code
  • Analyzing driver reliability/performance issues
  • Custom training mixed with consulting and focused directly on your specific areas of interest/concern.
Check us out. OSR, the Windows driver experts.

Monthly Seminars at OSR Headquarters

East Coast USA
Windows Internals and SW Drivers, Dulles (Sterling) VA, 13 November 2017

Kernel Debugging & Crash Analysis for Windows, Nashua (Amherst) NH, 4 December 2017

Writing WDF Drivers I: Core Concepts, Nashua (Amherst) NH, 8 January 2018

WDF Drivers II: Advanced Implementation Techniques, Nashua (Amherst) NH, 15 January 2018


Go Back   OSR Online Lists > ntdev
Welcome, Guest
You must login to post to this list
  Message 1 of 11  
11 Aug 17 19:04
Prokash Sinha
xxxxxx@gmail.com
Join Date: 28 Jun 2012
Posts To This List: 99
User-Kernel Communication

Hi All, I'm trying to get some design opinion about usr/krnl communication, and I know, or at least used to know that there are a few different options - 1) Using IOCTL 2) Shared Memory 3) Inverted Call 4) Optionally any other. Basically the kernel component will try to pump continuous data payload to the user mode components. Kernel component would be based on Wdf. Is there any suggestion or pointer to docs, that sheds light on high bandwidth transactions from kernel to user mode apps ? Only few commands, ack/nack will come to the kernel mode from user apps. TIA, Prokash
  Message 2 of 11  
11 Aug 17 19:32
Don Burn
xxxxxx@windrvr.com
Join Date: 23 Feb 2011
Posts To This List: 1349
User-Kernel Communication

While I always urge caution on shared memory this sounds like one of the = cases for it. I would use IOCTL's for the user mode to kernel = communication (use FASTIO if you need low overhead) and use the shared = memory for the data from the kernel. Don Burn Windows Driver Consulting Website: http://www.windrvr.com=20 -----Original Message----- From: xxxxx@lists.osr.com = [mailto:xxxxx@lists.osr.com] On Behalf Of Prokash Sinha = xxxxx@lists.osr.com Sent: Friday, August 11, 2017 7:03 PM To: Windows System Software Devs Interest List <xxxxx@lists.osr.com> Subject: [ntdev] User-Kernel Communication Hi All, I'm trying to get some design opinion about usr/krnl communication, and = I know, or at least used to know that there are a few different options = - 1) Using IOCTL 2) Shared Memory 3) Inverted Call 4) Optionally any other. Basically the kernel component will try to pump continuous data payload = to the user mode components. Kernel component would be based on Wdf. Is there any suggestion or pointer to docs, that sheds light on high = bandwidth transactions from kernel to user mode apps ? Only few = commands, ack/nack will come to the kernel mode from user apps. TIA, Prokash --- NTDEV is sponsored by OSR Visit the list online at: = <http://www.osronline.com/showlists.cfm?list=3Dntdev> MONTHLY seminars on crash dump analysis, WDF, Windows internals and = software drivers! Details at <http://www.osr.com/seminars> To unsubscribe, visit the List Server section of OSR Online at = <http://www.osronline.com/page.cfm?name=3DListServer>
  Message 3 of 11  
11 Aug 17 20:50
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11622
User-Kernel Communication

Prokash Sinha wrote: > Is there any suggestion or pointer to docs, that sheds light on high > bandwidth transactions from kernel to user mode apps ? Only few > commands, ack/nack will come to the kernel mode from user apps. What do you mean by "high bandwidth"? Is the data coming from a device, or generated by the kernel component? -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 4 of 11  
11 Aug 17 21:07
Prokash Sinha
xxxxxx@gmail.com
Join Date: 28 Jun 2012
Posts To This List: 99
User-Kernel Communication

Tim, it will be coming from a kernel component, as such no hardware devices involved except some hw devices are contributors to the traffic. -pro On Fri, Aug 11, 2017 at 5:49 PM, Tim Roberts <xxxxx@probo.com> <xxxxx@lists.osr.com> wrote: > Prokash Sinha wrote: >> Is there any suggestion or pointer to docs, that sheds light on high >> bandwidth transactions from kernel to user mode apps ? Only few >> commands, ack/nack will come to the kernel mode from user apps. > > What do you mean by "high bandwidth"? > > Is the data coming from a device, or generated by the kernel component? > > -- <...excess quoted lines suppressed...>
  Message 5 of 11  
11 Aug 17 21:09
Prokash Sinha
xxxxxx@gmail.com
Join Date: 28 Jun 2012
Posts To This List: 99
User-Kernel Communication

Thanks Don. Would consider this. Make sense. Pro On Fri, Aug 11, 2017 at 4:31 PM, Don Burn <xxxxx@windrvr.com> <xxxxx@lists.osr.com> wrote: > While I always urge caution on shared memory this sounds like one of the cases for it. I would use IOCTL's for the user mode to kernel communication (use FASTIO if you need low overhead) and use the shared memory for the data from the kernel. > > > Don Burn > Windows Driver Consulting > Website: http://www.windrvr.com > > > > -----Original Message----- <...excess quoted lines suppressed...>
  Message 6 of 11  
12 Aug 17 00:46
anton bassov
xxxxxx@hotmail.com
Join Date: 16 Jul 2006
Posts To This List: 4384
User-Kernel Communication

Shared memory seems to be the right way to go here,Pro..... For the purposes of simplicity you can implement it as an outstanding DIRECT_IO IOCTL that you pend in your driver, effectively getting a shared buffer that you can use for (possibly bi-directional) long-term communications between your app and kernel Anton Bassov
  Message 7 of 11  
12 Aug 17 01:19
Prokash Sinha
xxxxxx@gmail.com
Join Date: 28 Jun 2012
Posts To This List: 99
User-Kernel Communication

Anton, I think so too. Mainly because high intensity traffic. As Don pointed out the cmd+cntl would be using IOCNTL, a good separation of concern! Yeah, reading back those beautiful and short articles from the past issues of NT Insider. I just want to have a separate communication driver, with shared contexts, so that I can have multiple drivers feeding to the communication driver using shared context(s), mainly Queues ADT. The communication driver's sole responsibility would be cross the boundary to user space. Kinda got the idea, should be able to move and prototype. Basically, this is the design idea, I already implemented in Apple platform, and don't want to break the architecture since it is working fairly reliably, but being MACH & BSD driven kernel the implementation is different, but the architecture is intended to be same. Thanks to all of you! -Pro On Fri, Aug 11, 2017 at 9:45 PM, xxxxx@hotmail.com <xxxxx@lists.osr.com> wrote: > Shared memory seems to be the right way to go here,Pro..... > > For the purposes of simplicity you can implement it as an outstanding DIRECT_IO IOCTL that you pend in your driver, effectively getting a shared buffer that you can use for (possibly bi-directional) long-term communications between your app and kernel > > > Anton Bassov > > --- > NTDEV is sponsored by OSR > <...excess quoted lines suppressed...>
  Message 8 of 11  
12 Aug 17 01:36
anton bassov
xxxxxx@hotmail.com
Join Date: 16 Jul 2006
Posts To This List: 4384
User-Kernel Communication

> I just want to have a separate communication driver, with shared contexts, so that > I can have multiple drivers feeding to the communication driver using shared context(s), > mainly Queues ADT. The communication driver's sole responsibility would be cross the > boundary to user space. Are you trying to develop some kind of "NETLINK for Wndows" (at least conceptually, i.e. some generic mechanism for high-volume KM/UM communications that different apps and drivers can use)? Anton Bassov
  Message 9 of 11  
12 Aug 17 07:29
Prokash Sinha
xxxxxx@gmail.com
Join Date: 28 Jun 2012
Posts To This List: 99
User-Kernel Communication

Yep, that's the idea. So I was thinking about WSK too, but may be too much .... -Pro On Fri, Aug 11, 2017 at 10:35 PM, xxxxx@hotmail.com <xxxxx@lists.osr.com> wrote: > >> I just want to have a separate communication driver, with shared contexts, so that >> I can have multiple drivers feeding to the communication driver using shared context(s), >> mainly Queues ADT. The communication driver's sole responsibility would be cross the >> boundary to user space. > > > > Are you trying to develop some kind of "NETLINK for Wndows" (at least conceptually, i.e. some generic mechanism for high-volume KM/UM communications that different apps and drivers can use)? > <...excess quoted lines suppressed...>
  Message 10 of 11  
13 Aug 17 01:05
anton bassov
xxxxxx@hotmail.com
Join Date: 16 Jul 2006
Posts To This List: 4384
User-Kernel Communication

>So I was thinking about WSK too, but may be too much I would rather do things from the scratch........ I would write a "communication" driver that deals with KM components on the lower edge and with UM apps on the upper one. On the userland side I would encapsulate all the _actual_ dealing with the device in a library, effectively insulating the apps from all the "gory details" pretty much the same way Winsock API does - after all, socket-based client apps don't have to know that they are actually dealing with AFD.SYS behind the scenes, do they. I would apply the same logic here, and expose the whole thing in API that is reminiscent of the socket one (in this particular case it most certainly has to implement mmap() call, don't you think). In fact, if you are adventurous character you can go as far as implementing signal delivery (as an "inverted call") and select()/poll() API (as an IOCTL). On the KM side I would implement an internal IOCTL that returns a pointer to the table of function pointers to a caller, effectively implementing an interface of my own choice ( I guess NETLINK,again, can be used as a reference here) The "only" question is why should one bother himself with doing something like that, taking into account that we are speaking about a third-party driver that runs under the proprietary OS.After all, there are not that many drivers and apps that may potentially make any use of this framework,don't you think...... Anton Bassov
  Message 11 of 11  
13 Aug 17 07:10
Prokash Sinha
xxxxxx@gmail.com
Join Date: 28 Jun 2012
Posts To This List: 99
User-Kernel Communication

Sure you can try your ideas ... I know who would be using, when, how etc. So that is not the problem. Much of what you said is correct at the architecture level, but there are alternatives to it too :) And I sure will have to deal with Linux, after I'm done with this. So the order is Mac, Window, Linux. Permutation is fixed for me by others... Let's see ... -Pro On Sat, Aug 12, 2017 at 10:04 PM, xxxxx@hotmail.com <xxxxx@lists.osr.com> wrote: > >So I was thinking about WSK too, but may be too much > > > I would rather do things from the scratch........ > > > I would write a "communication" driver that deals with KM components on t= he lower edge and with UM apps on the upper one. On the userland side I wo= uld encapsulate all the _actual_ dealing with the device in a library, effe= ctively insulating the apps from all the "gory details" pretty much the sam= e way Winsock API does - after all, socket-based client apps don't have to= know that they are actually dealing with AFD.SYS behind the scenes, do the= y. I would apply the same logic here, and expose the whole thing in API tha= t is reminiscent of the socket one (in this particular case it most certain= ly has to implement mmap() call, don't you think). In fact, if you are adve= nturous character you can go as far as implementing signal delivery (as an = "inverted call") and select()/poll() API > (as an IOCTL). > > > On the KM side I would implement an internal IOCTL that returns a pointer= to the table of function pointers to a caller, effectively implementing an= interface of my own choice ( I guess NETLINK,again, can be used as a refer= ence here) > > > > The "only" question is why should one bother himself with doing somethin= g like that, taking into account that we are speaking about a third-party d= river that runs under the proprietary OS.After all, there are not that many= drivers and apps that may potentially make any use of this framework,don't= you think...... > > > > > Anton Bassov > > > > --- > NTDEV is sponsored by OSR <...excess quoted lines suppressed...> ntdev> > > MONTHLY seminars on crash dump analysis, WDF, Windows internals and softw= are drivers! > Details at <http://www.osr.com/seminars> > > To unsubscribe, visit the List Server section of OSR Online at <http://ww= w.osronline.com/page.cfm?name=3DListServer>
Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You must login to OSR Online AND be a member of the ntdev list to be able to post.

All times are GMT -5. The time now is 07:15.


Copyright ©2015, OSR Open Systems Resources, Inc.
Based on vBulletin Copyright ©2000 - 2005, Jelsoft Enterprises Ltd.
Modified under license