Prev: CondVar supported on Vista and Longorn??
Next: Administrator elevation via RPC fails on Vista, why?
From: Ronny S on 4 Mar 2006 16:56
Hi Tim,

Thanks again for your assistance. I would like to answer a couple of your
points:

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

We may have misread the GPL license, but in any case, the VNC paradigm won't
work for us as we are trying to developing an application publishing engine
(versus a desktop publishing engine, such as VNC).


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

I should have perhaps re-phrased point a):

The driver will need to support multiple clients and I was concerned it
would be constrained by the limited amount of non-paged pool memory available
to it. From what I read in the docs, a kernel driver should pre-allocate all
the memory it requires upon startup due to memory fragmentation, and should
not allocate more than 1 or 2 mb of memory. That does not seem like a
sufficient amount of memory to support more than a handful of clients
concurrently if they required large bitmaps.
From: Tim Roberts on 4 Mar 2006 20:18
Ronny S <RonnyS(a)discussions.microsoft.com> wrote:
>
>The driver will need to support multiple clients and I was concerned it
>would be constrained by the limited amount of non-paged pool memory available
>to it. From what I read in the docs, a kernel driver should pre-allocate all
>the memory it requires upon startup due to memory fragmentation, and should
>not allocate more than 1 or 2 mb of memory. That does not seem like a
>sufficient amount of memory to support more than a handful of clients
>concurrently if they required large bitmaps.

That's talking about contiguous memory -- memory where the pages have
consecutive physical addresses, which is only needed for DMA on devices
that don't do scatter/gather. For normal non-paged pool, you can allocate
a lot more than that.
--
- Tim Roberts, timr(a)probo.com
Providenza & Boekelheide, Inc.
From: Ivan Brugiolo [MSFT] on 5 Mar 2006 14:08
The Session space (on x86 before Vista, at least) is very limited in its
flavors of
Image-Mapping, View-Mapping, SessionPool.
If I were to implement what the OP is thinking about purely in kernel,
I would keep only the frame buffer of the mirror-driver in session space,
and, I would keep the connection-broker code
(implemented as some form of TDI-client) in some non-sessionized driver.
Managing the passing of the data from session-space in the context
of some DrvXXX call back to the TDI-Client may be some challenge on it's
own.

--
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


"Tim Roberts" <timr(a)probo.com> wrote in message
news:gsek021to26m3uas12njn8l9e5de19utob(a)4ax.com...
> Ronny S <RonnyS(a)discussions.microsoft.com> wrote:
>>
>>The driver will need to support multiple clients and I was concerned it
>>would be constrained by the limited amount of non-paged pool memory
>>available
>>to it. From what I read in the docs, a kernel driver should pre-allocate
>>all
>>the memory it requires upon startup due to memory fragmentation, and
>>should
>>not allocate more than 1 or 2 mb of memory. That does not seem like a
>>sufficient amount of memory to support more than a handful of clients
>>concurrently if they required large bitmaps.
>
> That's talking about contiguous memory -- memory where the pages have
> consecutive physical addresses, which is only needed for DMA on devices
> that don't do scatter/gather. For normal non-paged pool, you can allocate
> a lot more than that.
> --
> - Tim Roberts, timr(a)probo.com
> Providenza & Boekelheide, Inc.


From: Ronny S on 8 Mar 2006 16:23
I'm not exactly sure I understand - do your comments refer to implementation
completely within kernel?

Due to complexities of kernel driver programming, it appears I'll be better
served by implementation of the main body of code
(sockets/compression/encryption) in user-mode.

What, if any, are the challenges of sharing memory between the mirror driver
and the user mode application that must support multiple (dozens, or more)
clients concurrently. I apologize for the generality of the question, but
any hints (pitfalls to be avoided), etc. would be greatly appreciated.

Ronny

"Ivan Brugiolo [MSFT]" wrote:

> The Session space (on x86 before Vista, at least) is very limited in its
> flavors of
> Image-Mapping, View-Mapping, SessionPool.
> If I were to implement what the OP is thinking about purely in kernel,
> I would keep only the frame buffer of the mirror-driver in session space,
> and, I would keep the connection-broker code
> (implemented as some form of TDI-client) in some non-sessionized driver.
> Managing the passing of the data from session-space in the context
> of some DrvXXX call back to the TDI-Client may be some challenge on it's
> own.

First  |  Prev  | 
Pages: 1 2
Prev: CondVar supported on Vista and Longorn??
Next: Administrator elevation via RPC fails on Vista, why?