Prev: CondVar supported on Vista and Longorn??
Next: Administrator elevation via RPC fails on Vista, why?
From: Ronny S on 27 Feb 2006 16:51
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 (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.

Before implementation, however, I would like to get advice/recommendations
on the better approach to take.

Thanks in advance for your replies

Ronny
From: Tim Roberts on 1 Mar 2006 03:02
"Ronny S" <RonnyS(a)discussions.microsoft.com> 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(a)probo.com
Providenza & Boekelheide, Inc.
From: Ronny S on 1 Mar 2006 12:32
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(a)discussions.microsoft.com> 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(a)probo.com
> Providenza & Boekelheide, Inc.
>
From: Eugene Sukhodolin on 2 Mar 2006 14:53
Hi Ronny,

> 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.

It's not really a problem provided that you will ask the authors of mentioned
code directly :)
But please contact me OFF list if you're interested in commercial use.

--
Sincerely,
Eugene Sukhodolin
www.demoforge.com

From: Tim Roberts on 3 Mar 2006 00:59
"Ronny S" <RonnyS(a)discussions.microsoft.com> wrote:
>
>> 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).

You only have to publish the parts that are derived from VNC. I assume
your product does more than just what VNC does, otherwise no one would buy
it.

>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;

You're reading way too much into that recommendation. They're saying,
"when you need memory in a kernel driver, lookaside lists are a good way to
do that." However, lookaside lists are certainly NOT a reason to move code
into the kernel. There are a rich array of memory management schemes
available in user-mode, many of which are even better. Kernel mode has
traditionally had a dearth of such schemes.
--
- Tim Roberts, timr(a)probo.com
Providenza & Boekelheide, Inc.
 |  Next  |  Last
Pages: 1 2
Prev: CondVar supported on Vista and Longorn??
Next: Administrator elevation via RPC fails on Vista, why?