Everhart, Glenn From: Tony Mason [Mason@osr.com] Sent: Monday, February 22, 1999 10:54 AM To: 'Lin Feng'; Tony Mason Cc: 'Raul Carmenate Moreno'; ntfsd@atria.com; ntdev@atria.com Subject: [ntdev] RE: [ntfsd] calling user mode code ... Mr. Feng, Like many problems, there are several different possible solutions. I like the DeviceIoControl solution because it can be implemented to handle a large range of functions (via an operation code) and can work with one thread enqueuing many requests ("overlapped I/O" in Win32) or many threads enqueuing requests. Another more subtle advantage is that if the service opens the device and sends DeviceIoControl calls, if the service terminates the driver learns of this termination via the IRP_MJ_CLEANUP that this generates. Again, while not necessary for all solutions, my own typical usage is that I need to know if the service terminates so I don't leave other threads pending in the kernel waiting for the response from the (now defunct) service. Other possible solutions include using a shared memory segment (file backed section, paging file backed section, shared buffer) and an event pair, or I/O completion ports. All are valid solutions for kernel-to-user communications. For the specific question (calling a user mode DLL from a kernel mode driver) I personally believe that the inverted service mechanism is the best for several reasons: - It is general and easily extensible (via an "operations code") - It allows for using multiple threads to service the operations - It allows for asynchronous ("overlapped" in Win32) I/O to service the operations - It allows the kernel mode driver to detect the termination of the user mode service, and thus the kernel mode driver may unblock any threads waiting for responses as well as reject subsequent attempts to utilize the unavailable services. While I could simulate these using an event, it would involve additional mechanism (one or more events, shared memory buffers, outstanding opens on the device) that complicate the solution. That does not mean the alternative solution wouldn't work - just that it isn't the solution I considered to be the best in these particular circumstances. Regards, Tony Tony Mason Consulting Partner OSR Open Systems Resources, Inc. - http://www.osr.com Phone: +1 603 595 6500 FAX: +1 603 595 6503 Specializing in the development of file systems, device drivers and protocols for the Windows NT Kernel environment. -----Original Message----- From: Lin Feng [mailto:linlue@mbox3.singnet.com.sg] Sent: Sunday, February 21, 1999 9:37 PM To: Tony Mason Cc: 'Raul Carmenate Moreno'; ntfsd@atria.com; ntdev@atria.com Subject: Re: [ntfsd] calling user mode code ... It is easy to use "event" to help call user mode routine. You can create events in user mode and kernel mode. In user mode, create a thread and wait the event (WaitForSingleObject). When you want to run user mode routine, from kernel mode send an event to user mode to run WaitForSingleObject and your routine. Regards, Lin Feng Tony Mason wrote: > While you cannot directly call a user mode DLL from your kernel mode filter, > you can build a mechanism that accomplished the same basic effect. When I > teach about this I call it the "inverted call model". Specifically, you > build an NT service - the service can call the DLL since they are both in > user mode. You then create threads within the service and have them call > your driver (I like DeviceIoControl, but you can do this via any IRP_MJ > function...) > > In your driver, when you get these calls from your service, you take the > IRPs, mark them as pending and place them on a queue. > > Later, when you need to have the user mode DLL perform work you remove an > IRP from the queue. In the OUTPUT buffer, you build a "request block" > containing the information necessary for your user mode service to call the > DLL. Then, when you complete that IRP the thread in the service returns > from the DeviceIoControl. It looks at the data in the output buffer and > (based upon that information) calls the DLL. The results from the DLL are > then returned by the thread by making another DeviceIoControl (the > "response" is in the INPUT buffer.) In order to match up the "response" > with the "request" I usually use a request ID. > > I hope this helps. > > Regards, > > Tony > Tony Mason > Consulting Partner > OSR Open Systems Resources, Inc. > http://www.osr.com > > Specializing in consulting, development, and training for Windows NT > systems software, notably file systems and device drivers. > > > -----Original Message----- > > From: Raul Carmenate Moreno [mailto:rcm@seg.inf.cu] > > Sent: Friday, February 19, 1999 7:53 AM > > To: ntfsd@atria.com > > Cc: ntdev@atria.com > > Subject: [ntfsd] calling user mode code ... > > > > > > Hello All > > > > In my filter driver I need to detect openning of files , call > > a user mode > > DLL routine to check that file an according to the result let > > the openning > > go on or fail. How can I Call a user mode DLL from my filter > > Driver ?? or > > what technique I can use, may be signaling some way my DLL and waiting > > on a Semaphore ?? > > > > Thanks in advance > > > > --Raul > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > [ To unsubscribe, send email to ntfsd-request@atria.com with body > > UNSUBSCRIBE (the subject is ignored). ] > > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > [ To unsubscribe, send email to ntfsd-request@atria.com with body > UNSUBSCRIBE (the subject is ignored). ] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [ To unsubscribe, send email to ntfsd-request@atria.com with body UNSUBSCRIBE (the subject is ignored). ] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [ To unsubscribe, send email to ntdev-request@atria.com with body UNSUBSCRIBE (the subject is ignored). ]