Sure. I was just pointing out that your statement was a little absolute
(which I suppose is like being a little pregnant 
Ultimately the point is
that we actually hold kernel software to higher standards than user
software. Exposing the hardware up to user space, even if it is read-only
memory, does raise legitimate concerns.
The case that really annoys me is where it isnât a read-only memory buffer,
but read/write access to the entire register space of the device.
-----Original Message-----
From: Gregory G. Dyess [mailto:xxxxx@pdq.net]
Sent: Thursday, October 25, 2001 11:28 PM
To: NT Developers Interest List
Subject: [ntdev] RE: No right way to share PCI device memory with user mod
e?
Sorry for the misunderstanding. Several of the posts referred to the
user-mode application crashing the system, which cannot happen because of
the reasons I stated. I will grant you that system performance can be
easily degraded by doing just what you suggested. Then again, system
performance can be degraded by a user-mode application doing any number of
things. The first one that comes to mind is elevating priority to an
extremely high level and then executing a compute-bound busy loop.
Greg
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Mark Roddy
Sent: Thursday, October 25, 2001 8:48 PM
To: NT Developers Interest List
Subject: [ntdev] RE: No right way to share PCI device memory with user mod
e?
Not what I meant at all. The user program literally spins on a single byte
or word location in the shared memory region. It (the PCI mapped
region) is not cached. Each read operation results in a PCI bus transaction.
The PCI busâs performance will be seriously degraded by this continuous
useless polling.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gregory G. Dyess
Sent: Thursday, October 25, 2001 9:32 PM
To: NT Developers Interest List
Subject: [ntdev] RE: No right way to share PCI device memory with user
mod e?I think youâre missing something here. If the user just sits there
accessing VIRTUAL USER memory addresses, they will eventually pass a
USER VIRTUAL address that is past what is mapped to the I/O device.
When this happens, they will either fault with an access violation
(not a problem in user mode, just crash the app) or they will step
into memory that is mapped to something else. Neither will cause the
system to crash. If they write to the USER VIRTUAL addresses mapped
to the PCI device, nothing will happen as the device will
probably ignore write requests. Again, not a problem. Itâs
just like mapping a shared memory region, except instead of
RAM, it is a PCI device.If this were being done in Kernel mode, the story is completely
different.Greg
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Mark Roddy
Sent: Thursday, October 25, 2001 8:11 PM
To: NT Developers Interest List
Subject: [ntdev] RE: No right way to share PCI device memory with user
mod e?I think the statement âNote that the user mode application canât
possible do anything wrong by directly accessing the device buffer
since the buffer is read only.â Is a bit optimistic about the kind of
things that user mode (or
kernel) software can do either through stupidity or intentional
misconduct.Consider a user program that just spins in a loop fetching pci memory
forever. Ok, sure, bump it into real mode so it doesnât get priority
degraded due to quantum exhaustion. Yes the system probably wonât
crash but it sure will be slow.> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Tzvetan Mikov
> Sent: Thursday, October 25, 2001 4:22 PM
> To: NT Developers Interest List
> Subject: [ntdev] RE: No right way to share PCI device
memory with user
> mod e?
>
>
> I have to disagree. There are many good reasons to give user mode
> applications direct access to the device memory (not hardware in
> general, but device memory) and I would be surprised if NT was
> designed to explicitly to prevent that.
>
> If, to take a typical example, there is a 64MB read only
data buffer
> on the device, should all of that data be copied to user mode using
> IRPs? Note that the user mode application canât possible do
anything
> wrong by directly accessing the device buffer since the
buffer is read
> only.
>
> Another example is prototyping new hardware. From what Iâve seen
> designers usually use DOS or Linux to initially test their
hardware,
> since it is obviously impractical to write a NT kernel mode
driver for
> that purpose. Yes, in that case the user mode application
can easily
> crash the system, but still it has to be done.
>
> Anyway, prior to NT 4.0 the graphics drivers ran in user
mode and they
> did have access to the hardware, so that is a pretty strong
indication
> that such things are necessary and doable. Too bad that obviously
> nobody knows how to do it⌠I might have to use some of my
precious
> MSDN support
>
> -tzvetan
>
>
>
> ----- Original Message -----
> From: âHarmon, Larry CTâ
> > To: âNT Developers Interest Listâ
> > Sent: Thursday, October 25, 2001 4:08 AM
> > Subject: [ntdev] RE: No right way to share PCI device
> memory with user
> > mod e?
> >
> >
> > > tzvetan,
> > > There is no good way of sharing memory between a driver
> and a user
> > > mode
> > application. Thats why you havenât found any direct
> answers. NT was
> > designed to isolate the hardware from user tasks, so
> sharing memory is
> > contrary to NTâs design.
> > > NTâs archicture requires a kernel mode driver to pass
> data between
> > > devices
> > and applications. It isnât DOS.
> > >
> > > Larry
> >
> >
> >
> > â
> > You are currently subscribed to ntdev as: xxxxx@hollistech.com To
> > unsubscribe send a blank email to leave-ntdev-$subst(âRecip.MemberIDCharâ)@lists.osr.com
> >
> >
>
>
>
> â
> You are currently subscribed to ntdev as: xxxxx@pdq.net
> To unsubscribe send a blank email to leave-ntdev-$subst(âRecip.MemberIDCharâ)@lists.osr.com
>
>
> â
> You are currently subscribed to ntdev as: xxxxx@hollistech.com To
> unsubscribe send a blank email to leave-ntdev-$subst(âRecip.MemberIDCharâ)@lists.osr.com
>
>
â
You are currently subscribed to ntdev as: xxxxx@pdq.net
To unsubscribe send a blank email to leave-ntdev-$subst(âRecip.MemberIDCharâ)@lists.osr.com
â
You are currently subscribed to ntdev as: xxxxx@stratus.com To
unsubscribe send a blank email to leave-ntdev-$subst(âRecip.MemberIDCharâ)@lists.osr.com
â
You are currently subscribed to ntdev as: $subst(âRecip.EmailAddrâ)
To unsubscribe send a blank email to leave-ntdev-$subst(âRecip.MemberIDCharâ)@lists.osr.com