I want to set up a pointer to a status buffer in my device driver. Somebody
correct me if I am wrong but a way to do this is to create an Irp having
METHOD_NEITHER and accessing Irp-UserBuffer. I am seeing alot of doco that
says
never to do this. Anyone have a better way to do this?
FWIW,
Asher
There are two issues here, one is using method_neither and the other is
using pointers in data buffers. Without more information about what you are
trying to do, rather than what your solution is, it is difficult for me to
say anything more on this subject other than: here be dragons 
-----Original Message-----
From: Asher Hoodin [mailto:xxxxx@aam-ch.com]
Sent: Friday, March 08, 2002 7:17 AM
To: NT Developers Interest List
Subject: [ntdev] Irp->UserBufferI want to set up a pointer to a status buffer in my device
driver. Somebody correct me if I am wrong but a way to do
this is to create an Irp having METHOD_NEITHER and accessing
Irp-UserBuffer. I am seeing alot of doco that says never to
do this. Anyone have a better way to do this?FWIW,
Asher
You are currently subscribed to ntdev as:
xxxxx@stratus.com To unsubscribe send a blank email to
%%email.unsub%%
Well,
Without more information about what you are trying to do, rather than what
your solution is, it is difficult for me to say anything more on this
subject
Hope this helps to shed some light and open some gates!
I have a proprietary network card that I am converting from VxD to
WDM. Currently there is a buffer in the VxD that contains network status.
The Application has a pointer to this buffer. The pointer is set by calling
DeviceIoControl and passing back a user mode address.
I would like to do this with a WDM driver instead of VxD:
W32 app:
int install_lan( DWORD lan_physical_address, int lan_io_address, unsigned
char **netbfr,
NODE_STAT **statbfr, DWORD **timer, char *msg, LPVOID obj, int lan_num)
unsigned char inbuf[100], outbuf[100], tmpstr[100];
…
DeviceIoControl( hDevice, (DWORD)AAM_SET_ADDRESS, (LPVOID)inbuf,
(DWORD)sizeof(inbuf),
(LPVOID)outbuf, (DWORD)sizeof(outbuf), &bytes_returned, NULL);
ptr = (void*)outbuf;
*statbfr = (NODE_STAT*)*(ULONG*)ptr; // network stats for ALL LANS–WHERE
NODE_STAT IS A STRUCT THAT SHOWS the STATUS i WANT.
…
}
VxD:
DWORD OnW32Deviceiocontrol ( DIOCPARAMETERS *p)
{
ULONG *ptr;
unsigned char *ptr1, *ptr2, l;
int i,j;
switch( p->dwIoControlCode)
{…
case SET_ADDRESS:
ptr = (ULONG*) p->lpvInBuffer;
phy_addrs = *ptr; // physical LAN addrs
lin_addrs = _MapPhysToLinear((ULONG) phy_addrs, (ULONG)
(4*1024), (ULONG) 0);
DPRINTF0( buffer2, “Get Address\n”);
*(ULONG*) p->lpvInBuffer = msg_buffer; // return the addrs
of VxD msg buffer
*(ULONG*) p->lpvOutBuffer = (ULONG*)stat_buffer; // return the
addrs of VxD status buffer
global_timer = &base_timer; // temp test
*(unsigned long*)p->lpcbBytesReturned = &base_timer; // return
timer address
DPRINTF2( buffer3, “Msg Bfr: %lx, Stat Bfr: %lx\n”,msg_buffer,
stat_buffer);
return 0;
…
}
}
// Set LAN CPU physical and logical address
// phy addrs in lpvInBuffer
// Return VxD data addresses to the application
// lpvInBuffer = Address of message input buffer
// lpvOutBuffer = Address of net stat buffer
// bytes_returned = address of VxD timer
OK, I think method_neither has nothing to do with this. You are trying to
map either device memory or kernel memory (and I think it is kernel memory)
into user space. This is indeed generally a REAL BAD IDEA™ although it
is in fact do-able. The NT4 DDK contains a sample driver that maps device
memory into user space. This sample was removed from the w2k and later ddks.
I wonder why?
Instead your application, when it wants to know the status information,
should send an IOCTL to your driver and ask for the status information.
Porting from the hideous winDOS to NT is a good time to throw out all of the
bad old DOS style programming practices.
Mark Roddy
Consultant
Hollis Technology Solutions
xxxxx@hollistech.com
www.hollistech.com
603-321-1032
“Asher Hoodin” wrote in message news:xxxxx@ntdev…
>
> Well,
>
> >Without more information about what you are trying to do, rather than
what
> >your solution is, it is difficult for me to say anything more on this
> subject
> Hope this helps to shed some light and open some gates!
>
> I have a proprietary network card that I am converting from VxD to
> WDM. Currently there is a buffer in the VxD that contains network status.
> The Application has a pointer to this buffer. The pointer is set by
calling
> DeviceIoControl and passing back a user mode address.
>
> I would like to do this with a WDM driver instead of VxD:
>
> W32 app:
> int install_lan( DWORD lan_physical_address, int lan_io_address, unsigned
> char netbfr,
> NODE_STAT statbfr, DWORD **timer, char msg, LPVOID obj, int lan_num)
> unsigned char inbuf[100], outbuf[100], tmpstr[100];
> …
> DeviceIoControl( hDevice, (DWORD)AAM_SET_ADDRESS, (LPVOID)inbuf,
> (DWORD)sizeof(inbuf),
> (LPVOID)outbuf, (DWORD)sizeof(outbuf), &bytes_returned, NULL);
> ptr = (void)outbuf;
> statbfr = (NODE_STAT)(ULONG)ptr; // network stats for ALL LANS–WHERE
> NODE_STAT IS A STRUCT THAT SHOWS the STATUS i WANT.
> …
> }
> VxD:
> DWORD OnW32Deviceiocontrol ( DIOCPARAMETERS *p)
> {
> ULONG *ptr;
> unsigned char ptr1, ptr2, l;
> int i,j;
> switch( p->dwIoControlCode)
> {…
> case SET_ADDRESS:
> ptr = (ULONG) p->lpvInBuffer;
> phy_addrs = ptr; // physical LAN addrs
> lin_addrs = _MapPhysToLinear((ULONG) phy_addrs, (ULONG)
> (41024), (ULONG) 0);
> DPRINTF0( buffer2, “Get Address\n”);
> (ULONG) p->lpvInBuffer = msg_buffer; // return the addrs
> of VxD msg buffer
> (ULONG) p->lpvOutBuffer = (ULONG)stat_buffer; // return
the
> addrs of VxD status buffer
> global_timer = &base_timer; // temp test
> (unsigned long)p->lpcbBytesReturned = &base_timer; // return
> timer address
> DPRINTF2( buffer3, “Msg Bfr: %lx, Stat Bfr: %lx\n”,msg_buffer,
> stat_buffer);
> return 0;
> …
> }
> }
> // Set LAN CPU physical and logical address
> // phy addrs in lpvInBuffer
> // Return VxD data addresses to the application
> // lpvInBuffer = Address of message input buffer
> // lpvOutBuffer = Address of net stat buffer
> // bytes_returned = address of VxD timer
>
>
>
>
I sure am trying to map device memory into user space.
The NT4 DDK contains a sample driver that maps device
memory into user space.
Which sample is it ^namely^?
>Instead your application, when it wants to know the status information,
>should send an IOCTL to your driver and ask for the status information.
I agree that it is not the standard. However I am looking at a performance
issue. If I use the pointer to device memory, I have real time information
and real time control. If I need to send IOCTL from a loop to get my
status,
and send network messages, I am not as fast.
>Porting from the hideous winDOS to NT is a good time to throw out all of
the
>bad old DOS style programming practices.
What could the hardware guys do before the Windows came along? I think
Windows
is like the discovery of Fire. Now we cant stop burning the house down.
FWIW,
Asher
I have always imagined that Paradise will be a kind of library.
– Jorge Luis Borges
You may have those things, but you just violated every tenet of programming
in a secure, multi-user platform. Keep those hacks you described for the
toy operating systems line and do things the right way in NT.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Asher Hoodin
Sent: Friday, March 08, 2002 12:46 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Irp->UserBuffer
I sure am trying to map device memory into user space.
The NT4 DDK contains a sample driver that maps device
memory into user space.
Which sample is it ^namely^?
>Instead your application, when it wants to know the status information,
>should send an IOCTL to your driver and ask for the status information.
I agree that it is not the standard. However I am looking at a performance
issue. If I use the pointer to device memory, I have real time information
and real time control. If I need to send IOCTL from a loop to get my
status,
and send network messages, I am not as fast.
>Porting from the hideous winDOS to NT is a good time to throw out all of
the
>bad old DOS style programming practices.
What could the hardware guys do before the Windows came along? I think
Windows
is like the discovery of Fire. Now we cant stop burning the house down.
FWIW,
Asher
I have always imagined that Paradise will be a kind of library.
– Jorge Luis Borges
—
You are currently subscribed to ntdev as: xxxxx@pdq.net
To unsubscribe send a blank email to %%email.unsub%%
Better than the antiquated version of the example, simply get an Mdl for
your buffer, ProbeAndLock it then map it to the user process. If you call
into your driver to get the address of the buffer, this is where you should
perform the MmMap call since you in the context of the process, otherwise
you can call KeAttach to get in the correct context then map it.
Or you could memory map a file using same named object in both user and
kernel space.
Pete
Peter Scott
xxxxx@KernelDrivers.com
http://www.KernelDrivers.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Asher Hoodin
Sent: Friday, March 08, 2002 1:46 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Irp->UserBuffer
I sure am trying to map device memory into user space.
The NT4 DDK contains a sample driver that maps device
memory into user space.
Which sample is it ^namely^?
>Instead your application, when it wants to know the status information,
>should send an IOCTL to your driver and ask for the status information.
I agree that it is not the standard. However I am looking at a performance
issue. If I use the pointer to device memory, I have real time information
and real time control. If I need to send IOCTL from a loop to get my
status,
and send network messages, I am not as fast.
>Porting from the hideous winDOS to NT is a good time to throw out all of
the
>bad old DOS style programming practices.
What could the hardware guys do before the Windows came along? I think
Windows
is like the discovery of Fire. Now we cant stop burning the house down.
FWIW,
Asher
I have always imagined that Paradise will be a kind of library.
– Jorge Luis Borges
—
You are currently subscribed to ntdev as: xxxxx@KernelDrivers.com
To unsubscribe send a blank email to %%email.unsub%%
Which is the right way to do things in NT ? Id say it really depends by the
goals of a project, design guidelines, the target of a specific driver / app
pair, etc. Just look in the large world at many Real Time extensions for NT
, as an example, and see how they violate a lot of the rules and they use
plenty of hacks. In fact, when you know very well what you do, a hack might
be the best solution to accomplish safely a thing. By hack I understand
“unorthodox” things. I agree that someone should try to stick to documented
, Vatican aproved programming as long as he can. But when it’s out of
solutions what should he do ? Dont do a thing because the holy help file
does not documents it ?
Asher , Id say evaluate your options carefully , and choose whatever fits
you better, but be warned that sometimes MS might
refuse to sign drivers which they consider too “hacked”.
Regards , Dan
----- Original Message -----
From: “Gregory G. Dyess”
To: “NT Developers Interest List”
Sent: Friday, March 08, 2002 8:54 PM
Subject: [ntdev] Re: Irp->UserBuffer
> You may have those things, but you just violated every tenet of
programming
> in a secure, multi-user platform. Keep those hacks you described for the
> toy operating systems line and do things the right way in NT.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Asher Hoodin
> Sent: Friday, March 08, 2002 12:46 PM
> To: NT Developers Interest List
> Subject: [ntdev] Re: Irp->UserBuffer
>
>
> I sure am trying to map device memory into user space.
>
> >The NT4 DDK contains a sample driver that maps device
> >memory into user space.
>
> Which sample is it ^namely^?
>
> >Instead your application, when it wants to know the status information,
> >should send an IOCTL to your driver and ask for the status information.
>
> I agree that it is not the standard. However I am looking at a
performance
> issue. If I use the pointer to device memory, I have real time
information
> and real time control. If I need to send IOCTL from a loop to get my
> status,
> and send network messages, I am not as fast.
>
> >Porting from the hideous winDOS to NT is a good time to throw out all of
> the
> >bad old DOS style programming practices.
>
> What could the hardware guys do before the Windows came along? I think
> Windows
> is like the discovery of Fire. Now we cant stop burning the house down.
>
> FWIW,
>
> Asher
>
> I have always imagined that Paradise will be a kind of library.
> – Jorge Luis Borges
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@pdq.net
> To unsubscribe send a blank email to %%email.unsub%%
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to %%email.unsub%%
>
If the concern is that the cost of polling via an IOCTL is too high, then
the structured way to do this is to poll in the kernel using a system thread
and notify the application when the status buffer changes by completing a
pended irp. There is no need at all to map kernel space into user space in
his case. There are other design problems that do require such mappings,
this is not one of them.
-----Original Message-----
From: Pete Scott [mailto:xxxxx@KernelDrivers.com]
Sent: Friday, March 08, 2002 1:55 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Irp->UserBufferBetter than the antiquated version of the example, simply get
an Mdl for your buffer, ProbeAndLock it then map it to the
user process. If you call into your driver to get the address
of the buffer, this is where you should perform the MmMap
call since you in the context of the process, otherwise you
can call KeAttach to get in the correct context then map it.Or you could memory map a file using same named object in
both user and kernel space.Pete
Peter Scott
xxxxx@KernelDrivers.com
http://www.KernelDrivers.com-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Asher Hoodin
Sent: Friday, March 08, 2002 1:46 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Irp->UserBufferI sure am trying to map device memory into user space.
>The NT4 DDK contains a sample driver that maps device
>memory into user space.Which sample is it ^namely^?
>
> >Instead your application, when it wants to know the status
> information,
> >should send an IOCTL to your driver and ask for the status
> information.
>
> I agree that it is not the standard. However I am looking at
> a performance issue. If I use the pointer to device memory,
> I have real time information and real time control. If I
> need to send IOCTL from a loop to get my status, and send
> network messages, I am not as fast.
>
> >Porting from the hideous winDOS to NT is a good time to
> throw out all
> >of
> the
> >bad old DOS style programming practices.
>
> What could the hardware guys do before the Windows came
> along? I think Windows is like the discovery of Fire. Now
> we cant stop burning the house down.
>
> FWIW,
>
> Asher
>
> I have always imagined that Paradise will be a kind of library.
> – Jorge Luis Borges
>
>
>
> —
> You are currently subscribed to ntdev as:
> xxxxx@KernelDrivers.com To unsubscribe send a blank email to
> %%email.unsub%%
>
>
>
> —
> You are currently subscribed to ntdev as:
> xxxxx@stratus.com To unsubscribe send a blank email to
> %%email.unsub%%
>
/Soap box time!
In real time, you do special things, I agree. Real-time is my area of
expertise. However, in real-time, you also have very tight control over the
entire hw/sw/fw package and can get away with certain “unorthodox” things.
Generally, the same type of security is not an issue either. But if this is
a device and driver for general-purpose distribution into uncontrolled
configurations, as 99.999999% of these things are, then stick to the
guidelines or stick to the toy OSes. You don’t know how many times, I
cussed HW and driver writers because they save 0.5% of CPU time by doing
some hack that caused my SMP system to crash on a regular basis. Remember
the Matrox video cards that would hog the PCI bus until the other cards
timed out, all in the name of a couple % performance increase? I cringe
every time I hear someone say that “well we did it this way in Win 9x, so
I’m going to do it the same in NT/2K/XP”. They have no business doing any
development, let alone driver development in NT! It’s not MS that makes
NT/2K/XP so unstable. It’s the driver writers that have the entirely wrong
attitude for doing driver development that do!
Please let me know what network card/application this is you are developing
your driver for so I can make sure NOT to buy it and recommend noone else
does either!
/off my soap box now…
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Dan Partelly
Sent: Friday, March 08, 2002 12:55 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Irp->UserBuffer
Which is the right way to do things in NT ? Id say it really depends by the
goals of a project, design guidelines, the target of a specific driver / app
pair, etc. Just look in the large world at many Real Time extensions for NT
, as an example, and see how they violate a lot of the rules and they use
plenty of hacks. In fact, when you know very well what you do, a hack might
be the best solution to accomplish safely a thing. By hack I understand
“unorthodox” things. I agree that someone should try to stick to documented
, Vatican aproved programming as long as he can. But when it’s out of
solutions what should he do ? Dont do a thing because the holy help file
does not documents it ?
Asher , Id say evaluate your options carefully , and choose whatever fits
you better, but be warned that sometimes MS might
refuse to sign drivers which they consider too “hacked”.
Regards , Dan
----- Original Message -----
From: “Gregory G. Dyess”
To: “NT Developers Interest List”
Sent: Friday, March 08, 2002 8:54 PM
Subject: [ntdev] Re: Irp->UserBuffer
> You may have those things, but you just violated every tenet of
programming
> in a secure, multi-user platform. Keep those hacks you described for the
> toy operating systems line and do things the right way in NT.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Asher Hoodin
> Sent: Friday, March 08, 2002 12:46 PM
> To: NT Developers Interest List
> Subject: [ntdev] Re: Irp->UserBuffer
>
>
> I sure am trying to map device memory into user space.
>
> >The NT4 DDK contains a sample driver that maps device
> >memory into user space.
>
> Which sample is it ^namely^?
>
> >Instead your application, when it wants to know the status information,
> >should send an IOCTL to your driver and ask for the status information.
>
> I agree that it is not the standard. However I am looking at a
performance
> issue. If I use the pointer to device memory, I have real time
information
> and real time control. If I need to send IOCTL from a loop to get my
> status,
> and send network messages, I am not as fast.
>
> >Porting from the hideous winDOS to NT is a good time to throw out all of
> the
> >bad old DOS style programming practices.
>
> What could the hardware guys do before the Windows came along? I think
> Windows
> is like the discovery of Fire. Now we cant stop burning the house down.
>
> FWIW,
>
> Asher
>
> I have always imagined that Paradise will be a kind of library.
> – Jorge Luis Borges
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@pdq.net
> To unsubscribe send a blank email to %%email.unsub%%
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to %%email.unsub%%
>
—
You are currently subscribed to ntdev as: xxxxx@pdq.net
To unsubscribe send a blank email to %%email.unsub%%
I fully agree. I was just answering his question of how to map memory to a
user process …
Pete
Peter Scott
xxxxx@KernelDrivers.com
http://www.KernelDrivers.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Roddy, Mark
Sent: Friday, March 08, 2002 2:12 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Irp->UserBuffer
If the concern is that the cost of polling via an IOCTL is too high, then
the structured way to do this is to poll in the kernel using a system thread
and notify the application when the status buffer changes by completing a
pended irp. There is no need at all to map kernel space into user space in
his case. There are other design problems that do require such mappings,
this is not one of them.
-----Original Message-----
From: Pete Scott [mailto:xxxxx@KernelDrivers.com]
Sent: Friday, March 08, 2002 1:55 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Irp->UserBufferBetter than the antiquated version of the example, simply get
an Mdl for your buffer, ProbeAndLock it then map it to the
user process. If you call into your driver to get the address
of the buffer, this is where you should perform the MmMap
call since you in the context of the process, otherwise you
can call KeAttach to get in the correct context then map it.Or you could memory map a file using same named object in
both user and kernel space.Pete
Peter Scott
xxxxx@KernelDrivers.com
http://www.KernelDrivers.com-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Asher Hoodin
Sent: Friday, March 08, 2002 1:46 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Irp->UserBufferI sure am trying to map device memory into user space.
>The NT4 DDK contains a sample driver that maps device
>memory into user space.Which sample is it ^namely^?
>
> >Instead your application, when it wants to know the status
> information,
> >should send an IOCTL to your driver and ask for the status
> information.
>
> I agree that it is not the standard. However I am looking at
> a performance issue. If I use the pointer to device memory,
> I have real time information and real time control. If I
> need to send IOCTL from a loop to get my status, and send
> network messages, I am not as fast.
>
> >Porting from the hideous winDOS to NT is a good time to
> throw out all
> >of
> the
> >bad old DOS style programming practices.
>
> What could the hardware guys do before the Windows came
> along? I think Windows is like the discovery of Fire. Now
> we cant stop burning the house down.
>
> FWIW,
>
> Asher
>
> I have always imagined that Paradise will be a kind of library.
> – Jorge Luis Borges
>
>
>
> —
> You are currently subscribed to ntdev as:
> xxxxx@KernelDrivers.com To unsubscribe send a blank email to
> %%email.unsub%%
>
>
>
> —
> You are currently subscribed to ntdev as:
> xxxxx@stratus.com To unsubscribe send a blank email to
> %%email.unsub%%
>
—
You are currently subscribed to ntdev as: xxxxx@KernelDrivers.com
To unsubscribe send a blank email to %%email.unsub%%
Pete,
I appreciate the straight forward-ness of your reply.
Do you have some source that I can reference on the process of using the
Mdl?
If you do can you send me the source or a link?
THX++,
Asher
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Pete Scott
Sent: Friday, March 08, 2002 1:55 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Irp->UserBuffer
Better than the antiquated version of the example, simply get an Mdl for
your buffer, ProbeAndLock it then map it to the user process. If you call
into your driver to get the address of the buffer, this is where you should
perform the MmMap call since you in the context of the process, otherwise
you can call KeAttach to get in the correct context then map it.
Or you could memory map a file using same named object in both user and
kernel space.
Pete
Peter Scott
xxxxx@KernelDrivers.com
http://www.KernelDrivers.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Asher Hoodin
Sent: Friday, March 08, 2002 1:46 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Irp->UserBuffer
I sure am trying to map device memory into user space.
The NT4 DDK contains a sample driver that maps device
memory into user space.
Which sample is it ^namely^?
>Instead your application, when it wants to know the status information,
>should send an IOCTL to your driver and ask for the status information.
I agree that it is not the standard. However I am looking at a performance
issue. If I use the pointer to device memory, I have real time information
and real time control. If I need to send IOCTL from a loop to get my
status,
and send network messages, I am not as fast.
>Porting from the hideous winDOS to NT is a good time to throw out all of
the
>bad old DOS style programming practices.
What could the hardware guys do before the Windows came along? I think
Windows
is like the discovery of Fire. Now we cant stop burning the house down.
FWIW,
Asher
I have always imagined that Paradise will be a kind of library.
– Jorge Luis Borges
—
You are currently subscribed to ntdev as: xxxxx@KernelDrivers.com
To unsubscribe send a blank email to %%email.unsub%%
—
You are currently subscribed to ntdev as: xxxxx@aam-ch.com
To unsubscribe send a blank email to %%email.unsub%%
Rod,
the structured way to do this is to poll in the kernel using a system
thread
and notify the application when the status buffer changes by completing a
pended irp.
This part makes some sense. Got sample code of this kind of
operation/architecture?
There is no need at all to map kernel space into user space in
this case. There are other design problems that do require such mappings,
this is not one of them.
What about the context of porting over an existing application? Is
rewriting
an application with every release of NT the best route? (I am sure MS is
cashing
in on all this as well as alot of programmers, not that i mind.)
/Epsiode 426 - When Sally meet Harry
When a developer says “We did that on 9x , and doesnt work on NT” or “I
forgot NT is SMP able” that means that particular team did not made any
effort to understand operating systems issues , hardware architecture and so
on. I think they would better quit writting drivers or wait untill Visual
Basic Driver Edition will be released. Ignorance is not an excuse. I cursed
HW vendors too for their drivers , especially a ceratin DSL driver 
, but
that again is not an issue. I agree as well that MS does not make NT
instable , driver writters do. But MS has it’s share of guilt here, they
dont document enough the inner working of NT class OS’s.
Please let me know what network card/application this is you are
developing
your driver for so I can make sure NOT to buy it and recommend noone else
Right now I write a custom system for a customer, dont worry , you wont
have any chanche to buy it. And you can recomend to all your customers /
friends / whatever/ not to buy , you wont hurt me at all. And sorry, but
did you ever seen my code to
judge it and afford any comments like this ? I usualy dont judge things
which I did not seen. And if you work with real time platforms Im certain
you contribuited your own share of hacks to this wrold. Luckily, you always
knew what you did perfectly. Or so I hope
/Episode426 end
Best regards , Dan
----- Original Message -----
From: “Gregory G. Dyess”
To: “NT Developers Interest List”
Sent: Friday, March 08, 2002 9:25 PM
Subject: [ntdev] Re: Irp->UserBuffer
> /Soap box time!
>
> In real time, you do special things, I agree. Real-time is my area of
> expertise. However, in real-time, you also have very tight control over
the
> entire hw/sw/fw package and can get away with certain “unorthodox” things.
> Generally, the same type of security is not an issue either. But if this
is
> a device and driver for general-purpose distribution into uncontrolled
> configurations, as 99.999999% of these things are, then stick to the
> guidelines or stick to the toy OSes. You don’t know how many times, I
> cussed HW and driver writers because they save 0.5% of CPU time by doing
> some hack that caused my SMP system to crash on a regular basis. Remember
> the Matrox video cards that would hog the PCI bus until the other cards
> timed out, all in the name of a couple % performance increase? I cringe
> every time I hear someone say that “well we did it this way in Win 9x, so
> I’m going to do it the same in NT/2K/XP”. They have no business doing any
> development, let alone driver development in NT! It’s not MS that makes
> NT/2K/XP so unstable. It’s the driver writers that have the entirely
wrong
> attitude for doing driver development that do!
>
> Please let me know what network card/application this is you are
developing
> your driver for so I can make sure NOT to buy it and recommend noone else
> does either!
>
> /off my soap box now…
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Dan Partelly
> Sent: Friday, March 08, 2002 12:55 PM
> To: NT Developers Interest List
> Subject: [ntdev] Re: Irp->UserBuffer
>
>
> Which is the right way to do things in NT ? Id say it really depends by
the
> goals of a project, design guidelines, the target of a specific driver /
app
> pair, etc. Just look in the large world at many Real Time extensions for
NT
> , as an example, and see how they violate a lot of the rules and they use
> plenty of hacks. In fact, when you know very well what you do, a hack
might
> be the best solution to accomplish safely a thing. By hack I understand
> “unorthodox” things. I agree that someone should try to stick to
documented
> , Vatican aproved programming as long as he can. But when it’s out of
> solutions what should he do ? Dont do a thing because the holy help file
> does not documents it ?
>
> Asher , Id say evaluate your options carefully , and choose whatever fits
> you better, but be warned that sometimes MS might
> refuse to sign drivers which they consider too “hacked”.
>
> Regards , Dan
>
>
>
>
>
> ----- Original Message -----
> From: “Gregory G. Dyess”
> To: “NT Developers Interest List”
> Sent: Friday, March 08, 2002 8:54 PM
> Subject: [ntdev] Re: Irp->UserBuffer
>
>
> > You may have those things, but you just violated every tenet of
> programming
> > in a secure, multi-user platform. Keep those hacks you described for
the
> > toy operating systems line and do things the right way in NT.
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com]On Behalf Of Asher Hoodin
> > Sent: Friday, March 08, 2002 12:46 PM
> > To: NT Developers Interest List
> > Subject: [ntdev] Re: Irp->UserBuffer
> >
> >
> > I sure am trying to map device memory into user space.
> >
> > >The NT4 DDK contains a sample driver that maps device
> > >memory into user space.
> >
> > Which sample is it ^namely^?
> >
> > >Instead your application, when it wants to know the status information,
> > >should send an IOCTL to your driver and ask for the status information.
> >
> > I agree that it is not the standard. However I am looking at a
> performance
> > issue. If I use the pointer to device memory, I have real time
> information
> > and real time control. If I need to send IOCTL from a loop to get my
> > status,
> > and send network messages, I am not as fast.
> >
> > >Porting from the hideous winDOS to NT is a good time to throw out all
of
> > the
> > >bad old DOS style programming practices.
> >
> > What could the hardware guys do before the Windows came along? I think
> > Windows
> > is like the discovery of Fire. Now we cant stop burning the house down.
> >
> > FWIW,
> >
> > Asher
> >
> > I have always imagined that Paradise will be a kind of library.
> > – Jorge Luis Borges
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@pdq.net
> > To unsubscribe send a blank email to %%email.unsub%%
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@rdsor.ro
> > To unsubscribe send a blank email to %%email.unsub%%
> >
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@pdq.net
> To unsubscribe send a blank email to %%email.unsub%%
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to %%email.unsub%%
>
I don’t know if this will work, but maybe it’s worth a shot. Have an
IoControl subfunction in your driver that is called once and never returns:
it works in Direct Io mode, so, the OS does all the mdl dirty work, the
driver sees the user buffer for the duration of that function, which is
basically forever, or until the app issues another IoControl that unblocks
the original one. Now, have your driver asynchronously write your status to
that memory buffer. Have your app to fork out a thread that calls that magic
IoControl subfunction and nothing else: that will set up the buffer in a way
that’s visible to both app and driver. Have your app also have a thread that
calls the “unblock” IoControl subfunction when you want to terminate your
app. You did nothing that isn’t basically kosher, did you ? And would WHQL
kick my butt if I did that ?
Alberto.
-----Original Message-----
From: Asher Hoodin [mailto:xxxxx@aam-ch.com]
Sent: Friday, March 08, 2002 2:28 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Irp->UserBuffer
Pete,
I appreciate the straight forward-ness of your reply.
Do you have some source that I can reference on the process of using the
Mdl?
If you do can you send me the source or a link?
THX++,
Asher
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Pete Scott
Sent: Friday, March 08, 2002 1:55 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Irp->UserBuffer
Better than the antiquated version of the example, simply get an Mdl for
your buffer, ProbeAndLock it then map it to the user process. If you call
into your driver to get the address of the buffer, this is where you should
perform the MmMap call since you in the context of the process, otherwise
you can call KeAttach to get in the correct context then map it.
Or you could memory map a file using same named object in both user and
kernel space.
Pete
Peter Scott
xxxxx@KernelDrivers.com
http://www.KernelDrivers.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Asher Hoodin
Sent: Friday, March 08, 2002 1:46 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Irp->UserBuffer
I sure am trying to map device memory into user space.
The NT4 DDK contains a sample driver that maps device
memory into user space.
Which sample is it ^namely^?
>Instead your application, when it wants to know the status information,
>should send an IOCTL to your driver and ask for the status information.
I agree that it is not the standard. However I am looking at a performance
issue. If I use the pointer to device memory, I have real time information
and real time control. If I need to send IOCTL from a loop to get my
status,
and send network messages, I am not as fast.
>Porting from the hideous winDOS to NT is a good time to throw out all of
the
>bad old DOS style programming practices.
What could the hardware guys do before the Windows came along? I think
Windows
is like the discovery of Fire. Now we cant stop burning the house down.
FWIW,
Asher
I have always imagined that Paradise will be a kind of library.
– Jorge Luis Borges
—
You are currently subscribed to ntdev as: xxxxx@KernelDrivers.com
To unsubscribe send a blank email to %%email.unsub%%
—
You are currently subscribed to ntdev as: xxxxx@aam-ch.com
To unsubscribe send a blank email to %%email.unsub%%
—
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to %%email.unsub%%
It is so easy to talk in these generalities.
It is so easy to point the finger when your finger ain’t pointed at you.
Real-time is my area of
expertise. However, in real-time, you also have very tight control over
the
entire hw/sw/fw package and can get away with certain “unorthodox” things
You have a knack for the obvious.
99.999999%
You sound like one of these fangled people from PC Magazine that are doing
hardware reviews.
This is what you have in common with them:
You propose nothing.
You show no source code, and site no source code.
You havent written a device driver to save your life.
Dont signify nothing and mean nothing…that is not the route to go either.
What you could do but probably won’t because you think u know:
Please let me know what network card/application this is you are developing
your driver for so I can make sure NOT to buy it and recommend noone else
does either!
Pal I do what i want to do, but you should:
Learn to be nice and understanding.
You might try to learn something instead of pretendin’ that you know it all.
HTH!
Asher
I see you received many responses. Most of them pointed out the obvious
that what you want to do is not even close to a good idea. If the
application is running on a dedicated system, try running Linux which might
be close to performing a real time task. Better still, just buy a real time
OS and use it as it was designed.
You mention ‘real time’ in your message and Windows is not anything close to
‘real time’. There is no way to predict a maximum response time to
interrupts or an application becoming ready to run and when it begins
execution. Using a SMP system exclusively for your application, run as the
only user program on the system, might give you apparent ‘real time’
performance, but if you want to put it in the space shuttle, DON’T!
----- Original Message -----
From: “Asher Hoodin”
To: “NT Developers Interest List”
Sent: Friday, March 08, 2002 1:46 PM
Subject: [ntdev] Re: Irp->UserBuffer
> I sure am trying to map device memory into user space.
>
> >The NT4 DDK contains a sample driver that maps device
> >memory into user space.
>
> Which sample is it ^namely^?
>
> >Instead your application, when it wants to know the status information,
> >should send an IOCTL to your driver and ask for the status information.
>
> I agree that it is not the standard. However I am looking at a
performance
> issue. If I use the pointer to device memory, I have real time
information
> and real time control. If I need to send IOCTL from a loop to get my
> status,
> and send network messages, I am not as fast.
>
> >Porting from the hideous winDOS to NT is a good time to throw out all of
> the
> >bad old DOS style programming practices.
>
> What could the hardware guys do before the Windows came along? I think
> Windows
> is like the discovery of Fire. Now we cant stop burning the house down.
>
> FWIW,
>
> Asher
>
> I have always imagined that Paradise will be a kind of library.
> – Jorge Luis Borges
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@yoshimuni.com
> To unsubscribe send a blank email to %%email.unsub%%
>
Asher, I don’t know where you’ve been on this list, but if you’ve followed
it for a while, you’ll know that you are wrong about me and my background on
almost every count. I have the same response almost every time someone
proposes bypassing the OS.
Currently I am concentrating on mostly Windows CE platforms, but I do and
have done device drivers on NT, VMS and Windows CE. I do agree that NT is
the worst documented of the 3, but that is still no excuse to blatantly
ignore the guidelines that are documented.
True, it is easy to talk in generalities. Not always is that inappropriate.
Example: It is generally unsafe to drive your car at 100 MPH+ on a crowded
freeway during rush hour. Is that wrong to say just because it’s a
generality?
Maybe we could stop this type of attitude if companies and developers were
sued for writing code that caused systems to be unstable. Hmmm, would you
still want to hack things if you knew you could be sued for that extra 2%
performance increase or 1 week schedule gain? I think not…
This issue has raised itself several times over the past 3 or 4 years I have
been on this list. It always breaks down into a number of camps:
Which camp do you fall in?
Enough said this time. I’ll not say any more, until the next time it comes
up.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Asher Hoodin
Sent: Friday, March 08, 2002 2:02 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Irp->UserBuffer
It is so easy to talk in these generalities.
It is so easy to point the finger when your finger ain’t pointed at you.
Real-time is my area of
expertise. However, in real-time, you also have very tight control over
the
entire hw/sw/fw package and can get away with certain “unorthodox” things
You have a knack for the obvious.
99.999999%
You sound like one of these fangled people from PC Magazine that are doing
hardware reviews.
This is what you have in common with them:
You propose nothing.
You show no source code, and site no source code.
You havent written a device driver to save your life.
Dont signify nothing and mean nothing…that is not the route to go either.
What you could do but probably won’t because you think u know:
Please let me know what network card/application this is you are developing
your driver for so I can make sure NOT to buy it and recommend noone else
does either!
Pal I do what i want to do, but you should:
Learn to be nice and understanding.
You might try to learn something instead of pretendin’ that you know it all.
HTH!
Asher
You are currently subscribed to ntdev as: xxxxx@pdq.net
To unsubscribe send a blank email to %%email.unsub%%
Actually I want to stay in close sync with a dual port on a fast
proprietary fiberoptic serial device.
Using a SMP system exclusively for your application, run as the
only user program on the system, might give you apparent ‘real time’
performance, but if you want to put it in the space shuttle, DON’T!
The Windows version that crashed the space shuttle? XP in space! Fun.
I can see the headlines XP otherwise known as space junk!
Asher
You were faster 
Well, one small change: don’t use never-returning
functions and return pending status instead. Also, it isn’t necessary to
make unblock IOCTL, proper IRP_MJ_CLEANUP handling should be enough. It is
issued when application closes the handle so driver can complete all pending
IOCTLs for that app. I’m not quite sure now if it is also issued when app
dies or is killed; if not, proper cancel handling is necessary. No, don’t
recall an example, examine DDK, please.
A note to original poster which isn’t mentioned as a flame: it is always
better to try a standard solution at first and make optimalization only if
really necessary. Maybe you’ll be surprised it is fast enough and a hack is
pointless. And yes, rewriting an app comming from w9x to NT is a good idea.
If you use standard ways on NT, no next rewrites would be necessary for next
NT versions.
Best regards,
Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]
From:
xxxxx@compuware.com[SMTP:xxxxx@compuware.com]
Reply To: xxxxx@lists.osr.com
Sent: Friday, March 08, 2002 8:44 PM
To: xxxxx@lists.osr.com
Subject: [ntdev] Re: Irp->UserBufferI don’t know if this will work, but maybe it’s worth a shot. Have an
IoControl subfunction in your driver that is called once and never
returns:
it works in Direct Io mode, so, the OS does all the mdl dirty work, the
driver sees the user buffer for the duration of that function, which is
basically forever, or until the app issues another IoControl that unblocks
the original one. Now, have your driver asynchronously write your status
to
that memory buffer. Have your app to fork out a thread that calls that
magic
IoControl subfunction and nothing else: that will set up the buffer in a
way
that’s visible to both app and driver. Have your app also have a thread
that
calls the “unblock” IoControl subfunction when you want to terminate your
app. You did nothing that isn’t basically kosher, did you ? And would WHQL
kick my butt if I did that ?Alberto.
-----Original Message-----
From: Asher Hoodin [mailto:xxxxx@aam-ch.com]
Sent: Friday, March 08, 2002 2:28 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Irp->UserBufferPete,
I appreciate the straight forward-ness of your reply.
Do you have some source that I can reference on the process of using the
Mdl?If you do can you send me the source or a link?
THX++,
Asher
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Pete Scott
Sent: Friday, March 08, 2002 1:55 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Irp->UserBufferBetter than the antiquated version of the example, simply get an Mdl for
your buffer, ProbeAndLock it then map it to the user process. If you call
into your driver to get the address of the buffer, this is where you
should
perform the MmMap call since you in the context of the process, otherwise
you can call KeAttach to get in the correct context then map it.Or you could memory map a file using same named object in both user and
kernel space.Pete
Peter Scott
xxxxx@KernelDrivers.com
http://www.KernelDrivers.com-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Asher Hoodin
Sent: Friday, March 08, 2002 1:46 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Irp->UserBufferI sure am trying to map device memory into user space.
>The NT4 DDK contains a sample driver that maps device
>memory into user space.Which sample is it ^namely^?
>
> >Instead your application, when it wants to know the status information,
> >should send an IOCTL to your driver and ask for the status information.
>
> I agree that it is not the standard. However I am looking at a
> performance
> issue. If I use the pointer to device memory, I have real time
> information
> and real time control. If I need to send IOCTL from a loop to get my
> status,
> and send network messages, I am not as fast.
>
> >Porting from the hideous winDOS to NT is a good time to throw out all of
> the
> >bad old DOS style programming practices.
>
> What could the hardware guys do before the Windows came along? I think
> Windows
> is like the discovery of Fire. Now we cant stop burning the house down.
>
> FWIW,
>
> Asher
>
> I have always imagined that Paradise will be a kind of library.
> – Jorge Luis Borges
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@KernelDrivers.com
> To unsubscribe send a blank email to %%email.unsub%%
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@aam-ch.com
> To unsubscribe send a blank email to %%email.unsub%%
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@compuware.com
> To unsubscribe send a blank email to %%email.unsub%%
>
> —
> You are currently subscribed to ntdev as: michal.vodicka@st.com
> To unsubscribe send a blank email to %%email.unsub%%
>