Re: Mirror Driver Architecture
- From: "Ronny S" <RonnyS@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 1 Mar 2006 09:32:59 -0800
Hi Tim, thanks for the reply.
Before you embark on a multimonth development effort, have you checked out
the various VNCs, which do exactly what you are asking, and come with
source code?
Unfortunately the VNC family of products are licensed under GPL which means
we can't use them unless we publish our own source code (this is a commercial
application we are developing). Additionally, the mirror drivers included
with the VNC products do not come with source code.
You need to weigh the "headache of managing the shared memory" to the
headache of compression and encryption in the driver, plus the risks of
kernel debugging versus the ease of user debugging, PLUS the headache of
mucking with TDI versus the ease of socket programming.
You are right, of course, any kind of programming in the kernel seems to be
non-trivial - especially TDI or encryption where no libraries seem to exist
(other than FIPS which is undocumented and subject to abandonment by
Microsoft).
The reason I thought this might be the right architecture is twofold:
a) sharing memory with user mode would require pre-allocation of a memory
buffer from the non-paged pool (a limited resource), would require
synchronization, notification etc., whereas doing everything in kernel mode
would be able to take advantage of lookaside lists, a preferred method of
memory usage in kernel drivers according to Microsoft documentation;
b) this might seem silly, but I noticed placeholders in the DDK mirror
driver sample code - specifically DrvBitBlt and DrvCopyBits - for sending
data over the wire and for data compression, and I thought they might be
guidelines for the correct design.
Your responses are appreciated.
Ronny
"Tim Roberts" wrote:
"Ronny S" <RonnyS@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:.
I am building a mirror driver that needs to compress, encrypt and transmit
bytes over a network. I believe it would be more efficient to do this from
within the driver rather than requesting the user-mode application to
perform these tasks every time there is a modification to the UI.
My understanding is that these kernel to user-mode context switches are
costly...
Compared to what? You're talking about compressing, encrypting, and
transmitting over a network here. The overhead of a couple of user/kernel
transition will be lost in the noise.
Before you embark on a multimonth development effort, have you checked out
the various VNCs, which do exactly what you are asking, and come with
source code?
(as are the synchronizations on shared memory, etc.) - not to mention
the additional headache of managing the shared memory in the driver - so I
opted for doing everything in the driver.
You need to weigh the "headache of managing the shared memory" to the
headache of compression and encryption in the driver, plus the risks of
kernel debugging versus the ease of user debugging, PLUS the headache of
mucking with TDI versus the ease of socket programming.
I've been doing Windows drivers for 16 years, but given the choice, I'll
always push the work to user-mode.
--
- Tim Roberts, timr@xxxxxxxxx
Providenza & Boekelheide, Inc.
- Follow-Ups:
- Re: Mirror Driver Architecture
- From: Tim Roberts
- Re: Mirror Driver Architecture
- From: Eugene Sukhodolin
- Re: Mirror Driver Architecture
- References:
- Re: Mirror Driver Architecture
- From: Tim Roberts
- Re: Mirror Driver Architecture
- Prev by Date: Re: Reading Current User registry before logon
- Next by Date: Fiber memory usage
- Previous by thread: Re: Mirror Driver Architecture
- Next by thread: Re: Mirror Driver Architecture
- Index(es):
Relevant Pages
|
