basic question

The question is why, in layered drivers structure, everything has to be passed
via IRPs ? Why is it not recommended for one driver to export functions which
can be used by lower/other drivers ? What is the danger here ?

regards,
Hassan


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

One of the more basic rules you would be breaking is when a driver is
layered between you and the driver you talk directly to, the ‘in between’
driver would never see any of the requests passed down the stack. This is
only one issue, there are many.

Peter Scott
xxxxx@KernelDrivers.com
http://www.KernelDrivers.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Hassan Khan
Sent: Wednesday, April 18, 2001 4:33 PM
To: NT Developers Interest List
Subject: [ntdev] basic question

The question is why, in layered drivers structure, everything has to be
passed
via IRPs ? Why is it not recommended for one driver to export functions
which
can be used by lower/other drivers ? What is the danger here ?

regards,
Hassan


You are currently subscribed to ntdev as: xxxxx@home.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

Thats right. But it seems to me to be the only reason. I just came across
an NT Insider article ‘Driver to Driver communication’ , which kind of
encourage using ‘shared context’ between drivers. Basically a
non-IRP approach. Conclusion I am making here is (I could be wrong) if you
are sure that there will never be a need for any filter driver because you
are providing all the layers you need for this kind of device then its much
efficient to use your own communication method rather than sending your data
to NT Kernel first each time you want to send it to lower/other drivers in
the hierarchy.

regards,
Hassan

Pete Scott wrote:

One of the more basic rules you would be breaking is when a driver is
layered between you and the driver you talk directly to, the ‘in between’
driver would never see any of the requests passed down the stack. This is
only one issue, there are many.

Peter Scott
xxxxx@KernelDrivers.com
http://www.KernelDrivers.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Hassan Khan
Sent: Wednesday, April 18, 2001 4:33 PM
To: NT Developers Interest List
Subject: [ntdev] basic question

The question is why, in layered drivers structure, everything has to be
passed
via IRPs ? Why is it not recommended for one driver to export functions
which
can be used by lower/other drivers ? What is the danger here ?

regards,
Hassan


You are currently subscribed to ntdev as: xxxxx@home.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntdev as: xxxxx@trimedia.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

Hi Hassan:
When you talk about the ‘shared context’, I think it’s a data structure
instead of some exported function if you write in C. In my 3-layer driver,
which is like this:
Serial Driver
Filter
Bus Extender Driver
I want to get the bus slot from serial driver, I have two choices: one is
use INTERNAL_IOCONTROL which allow drivers to talk to each other, the other
choice, the one I choose, is to get a pointer to the Bus Extender’s Device
Extension in Serial Driver’s Device Extension . Then you can reference the
bus information simply by query the linked list. The code looks like this:
DeviceData->SlotIndex =
((PPDO_DEVICE_DATA)DeviceData->UnderlyingPDO->DeviceExtension)->SlotIndex;
All you need to do is to store pointers to lower device’s device extension
when creating the upper layered device.

HIH

Alex Dong
Advantech, R&D Center, Beijing
xxxxx@advantech.com.cn

----- Original Message -----
From: “Hassan Khan”
To: “NT Developers Interest List”
Sent: Wednesday, April 18, 2001 4:28 PM
Subject: [ntdev] RE: basic question

> Thats right. But it seems to me to be the only reason. I just came
across
> an NT Insider article ‘Driver to Driver communication’ , which kind of
> encourage using ‘shared context’ between drivers. Basically a
> non-IRP approach. Conclusion I am making here is (I could be wrong) if
you
> are sure that there will never be a need for any filter driver because you
> are providing all the layers you need for this kind of device then its
much
> efficient to use your own communication method rather than sending your
data
> to NT Kernel first each time you want to send it to lower/other drivers in
> the hierarchy.
>
> regards,
> Hassan
>
> Pete Scott wrote:
>
> > One of the more basic rules you would be breaking is when a driver is
> > layered between you and the driver you talk directly to, the ‘in
between’
> > driver would never see any of the requests passed down the stack. This
is
> > only one issue, there are many.
> >
> > Peter Scott
> > xxxxx@KernelDrivers.com
> > http://www.KernelDrivers.com
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com]On Behalf Of Hassan Khan
> > Sent: Wednesday, April 18, 2001 4:33 PM
> > To: NT Developers Interest List
> > Subject: [ntdev] basic question
> >
> > The question is why, in layered drivers structure, everything has to be
> > passed
> > via IRPs ? Why is it not recommended for one driver to export functions
> > which
> > can be used by lower/other drivers ? What is the danger here ?
> >
> > regards,
> > Hassan
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@home.com
> > To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@trimedia.com
> > To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@advantech.com.cn
> 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

Hi Dong,

As the article (Driver to Driver communication) states you can store a
function’s address in the shared context just like anything else. And as long
as you ‘know’ the prototype you can safely call that function using that
address ( talking in terms of C ).

But looking into the DDK I found that there is something thats called
EXPORT_DRIVER (TARGETTYPE=EXPORT_DRIVER in the sources file ) which export
functions to other kernel-mode drivers …probably Ndis.sys is one such
example. I don’t know yet how do you actually export functions in this type of
target. May be some .def file. If anybody knows about this method please help.

Regards,
Hassan

Dong Xun wrote:

Hi Hassan:
When you talk about the ‘shared context’, I think it’s a data structure
instead of some exported function if you write in C. In my 3-layer driver,
which is like this:
Serial Driver
Filter
Bus Extender Driver
I want to get the bus slot from serial driver, I have two choices: one is
use INTERNAL_IOCONTROL which allow drivers to talk to each other, the other
choice, the one I choose, is to get a pointer to the Bus Extender’s Device
Extension in Serial Driver’s Device Extension . Then you can reference the
bus information simply by query the linked list. The code looks like this:
DeviceData->SlotIndex =
((PPDO_DEVICE_DATA)DeviceData->UnderlyingPDO->DeviceExtension)->SlotIndex;
All you need to do is to store pointers to lower device’s device extension
when creating the upper layered device.

HIH

Alex Dong
Advantech, R&D Center, Beijing
xxxxx@advantech.com.cn

----- Original Message -----
From: “Hassan Khan”
> To: “NT Developers Interest List”
> Sent: Wednesday, April 18, 2001 4:28 PM
> Subject: [ntdev] RE: basic question
>
> > Thats right. But it seems to me to be the only reason. I just came
> across
> > an NT Insider article ‘Driver to Driver communication’ , which kind of
> > encourage using ‘shared context’ between drivers. Basically a
> > non-IRP approach. Conclusion I am making here is (I could be wrong) if
> you
> > are sure that there will never be a need for any filter driver because you
> > are providing all the layers you need for this kind of device then its
> much
> > efficient to use your own communication method rather than sending your
> data
> > to NT Kernel first each time you want to send it to lower/other drivers in
> > the hierarchy.
> >
> > regards,
> > Hassan
> >
> > Pete Scott wrote:
> >
> > > One of the more basic rules you would be breaking is when a driver is
> > > layered between you and the driver you talk directly to, the ‘in
> between’
> > > driver would never see any of the requests passed down the stack. This
> is
> > > only one issue, there are many.
> > >
> > > Peter Scott
> > > xxxxx@KernelDrivers.com
> > > http://www.KernelDrivers.com
> > >
> > > -----Original Message-----
> > > From: xxxxx@lists.osr.com
> > > [mailto:xxxxx@lists.osr.com]On Behalf Of Hassan Khan
> > > Sent: Wednesday, April 18, 2001 4:33 PM
> > > To: NT Developers Interest List
> > > Subject: [ntdev] basic question
> > >
> > > The question is why, in layered drivers structure, everything has to be
> > > passed
> > > via IRPs ? Why is it not recommended for one driver to export functions
> > > which
> > > can be used by lower/other drivers ? What is the danger here ?
> > >
> > > regards,
> > > Hassan
> > >
>


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

Hi Hassan:
I have checked the DDK and online knowledge base, no result
returns. But when I check the www.deja.com , the newsgroup:
comp.os.ms-windows.programmer.nt.kernel-mode , I did find something useful.
Please try it yourself.
It seems that once you define the EXPORT_DRIVER macro in your
SOURCES file, all of your functions could be called from other drivers. This
is a pretty new idea and I haven’t tried it yet. If you got some idea on how
this works, please post it here to share with us.
Also could you mail me a copy of the file you mentioned privately to
xxxxx@advantech.com.cn ? Thanks in advance.

Hope it help
Alex

Advantech , R&D Center, Beijing
xxxxx@advantech.com.cn

----- Original Message -----
From: “Hassan Khan”
To: “NT Developers Interest List”
Sent: Wednesday, April 18, 2001 7:09 PM
Subject: [ntdev] RE: basic question

> Hi Dong,
>
> As the article (Driver to Driver communication) states you can store a
> function’s address in the shared context just like anything else. And as
long
> as you ‘know’ the prototype you can safely call that function using that
> address ( talking in terms of C ).
>
> But looking into the DDK I found that there is something thats called
> EXPORT_DRIVER (TARGETTYPE=EXPORT_DRIVER in the sources file ) which
export
> functions to other kernel-mode drivers …probably Ndis.sys is one such
> example. I don’t know yet how do you actually export functions in this
type of
> target. May be some .def file. If anybody knows about this method please
help.
>
> Regards,
> Hassan
>
>
> Dong Xun wrote:
>
> > Hi Hassan:
> > When you talk about the ‘shared context’, I think it’s a data
structure
> > instead of some exported function if you write in C. In my 3-layer
driver,
> > which is like this:
> > Serial Driver
> > Filter
> > Bus Extender Driver
> > I want to get the bus slot from serial driver, I have two choices: one
is
> > use INTERNAL_IOCONTROL which allow drivers to talk to each other, the
other
> > choice, the one I choose, is to get a pointer to the Bus Extender’s
Device
> > Extension in Serial Driver’s Device Extension . Then you can reference
the
> > bus information simply by query the linked list. The code looks like
this:
> > DeviceData->SlotIndex =
> >
((PPDO_DEVICE_DATA)DeviceData->UnderlyingPDO->DeviceExtension)->SlotIndex;
> > All you need to do is to store pointers to lower device’s device
extension
> > when creating the upper layered device.
> >
> > HIH
> >
> > Alex Dong
> > Advantech, R&D Center, Beijing
> > xxxxx@advantech.com.cn
> >
> > ----- Original Message -----
> > From: “Hassan Khan”
> > To: “NT Developers Interest List”
> > Sent: Wednesday, April 18, 2001 4:28 PM
> > Subject: [ntdev] RE: basic question
> >
> > > Thats right. But it seems to me to be the only reason. I just came
> > across
> > > an NT Insider article ‘Driver to Driver communication’ , which kind of
> > > encourage using ‘shared context’ between drivers. Basically a
> > > non-IRP approach. Conclusion I am making here is (I could be wrong)
if
> > you
> > > are sure that there will never be a need for any filter driver because
you
> > > are providing all the layers you need for this kind of device then its
> > much
> > > efficient to use your own communication method rather than sending
your
> > data
> > > to NT Kernel first each time you want to send it to lower/other
drivers in
> > > the hierarchy.
> > >
> > > regards,
> > > Hassan
> > >
> > > Pete Scott wrote:
> > >
> > > > One of the more basic rules you would be breaking is when a driver
is
> > > > layered between you and the driver you talk directly to, the ‘in
> > between’
> > > > driver would never see any of the requests passed down the stack.
This
> > is
> > > > only one issue, there are many.
> > > >
> > > > Peter Scott
> > > > xxxxx@KernelDrivers.com
> > > > http://www.KernelDrivers.com
> > > >
> > > > -----Original Message-----
> > > > From: xxxxx@lists.osr.com
> > > > [mailto:xxxxx@lists.osr.com]On Behalf Of Hassan Khan
> > > > Sent: Wednesday, April 18, 2001 4:33 PM
> > > > To: NT Developers Interest List
> > > > Subject: [ntdev] basic question
> > > >
> > > > The question is why, in layered drivers structure, everything has to
be
> > > > passed
> > > > via IRPs ? Why is it not recommended for one driver to export
functions
> > > > which
> > > > can be used by lower/other drivers ? What is the danger here ?
> > > >
> > > > regards,
> > > > Hassan
> > > >
> >
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@advantech.com.cn
> 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

There is an article in the NT Insider that shows how to
develop an EXPORT_DRIVER. The thing to realize
with all these approaches is that “NEVER USE A
SPECIAL MECHANISM IF THE STANDARD
APPROACH WORKS!”.

I have built drivers that share a function block or
export routines, but in all cases I was in need of functionality
closer to a Class driver. I had a set of functionality
that was common to a set of devices, and another
driver that supported a specific interface. The last thing
you want to do is think “gee I can make my own write
routine that my upper level driver will use”.

Like all work in the kernel it is a matter of tradeoffs, but
stick to the basics if you can. Especially if someone may
want to submit your driver to WHQL for testing one
day.

Don Burn
Windows 2000 Device Driver and Filesystem consulting

----- Original Message -----
From: “Hassan Khan”
To: “NT Developers Interest List”
Sent: Wednesday, April 18, 2001 10:09 PM
Subject: [ntdev] RE: basic question

> Hi Dong,
>
> As the article (Driver to Driver communication) states you can store a
> function’s address in the shared context just like anything else. And as
long
> as you ‘know’ the prototype you can safely call that function using that
> address ( talking in terms of C ).
>
> But looking into the DDK I found that there is something thats called
> EXPORT_DRIVER (TARGETTYPE=EXPORT_DRIVER in the sources file ) which
export
> functions to other kernel-mode drivers …probably Ndis.sys is one such
> example. I don’t know yet how do you actually export functions in this
type of
> target. May be some .def file. If anybody knows about this method please
help.
>
> Regards,
> Hassan
>
>
> Dong Xun wrote:
>
> > Hi Hassan:
> > When you talk about the ‘shared context’, I think it’s a data
structure
> > instead of some exported function if you write in C. In my 3-layer
driver,
> > which is like this:
> > Serial Driver
> > Filter
> > Bus Extender Driver
> > I want to get the bus slot from serial driver, I have two choices: one
is
> > use INTERNAL_IOCONTROL which allow drivers to talk to each other, the
other
> > choice, the one I choose, is to get a pointer to the Bus Extender’s
Device
> > Extension in Serial Driver’s Device Extension . Then you can reference
the
> > bus information simply by query the linked list. The code looks like
this:
> > DeviceData->SlotIndex =
> >
((PPDO_DEVICE_DATA)DeviceData->UnderlyingPDO->DeviceExtension)->SlotIndex;
> > All you need to do is to store pointers to lower device’s device
extension
> > when creating the upper layered device.
> >
> > HIH
> >
> > Alex Dong
> > Advantech, R&D Center, Beijing
> > xxxxx@advantech.com.cn
> >
> > ----- Original Message -----
> > From: “Hassan Khan”
> > To: “NT Developers Interest List”
> > Sent: Wednesday, April 18, 2001 4:28 PM
> > Subject: [ntdev] RE: basic question
> >
> > > Thats right. But it seems to me to be the only reason. I just came
> > across
> > > an NT Insider article ‘Driver to Driver communication’ , which kind of
> > > encourage using ‘shared context’ between drivers. Basically a
> > > non-IRP approach. Conclusion I am making here is (I could be wrong)
if
> > you
> > > are sure that there will never be a need for any filter driver because
you
> > > are providing all the layers you need for this kind of device then its
> > much
> > > efficient to use your own communication method rather than sending
your
> > data
> > > to NT Kernel first each time you want to send it to lower/other
drivers in
> > > the hierarchy.
> > >
> > > regards,
> > > Hassan
> > >
> > > Pete Scott wrote:
> > >
> > > > One of the more basic rules you would be breaking is when a driver
is
> > > > layered between you and the driver you talk directly to, the ‘in
> > between’
> > > > driver would never see any of the requests passed down the stack.
This
> > is
> > > > only one issue, there are many.
> > > >
> > > > Peter Scott
> > > > xxxxx@KernelDrivers.com
> > > > http://www.KernelDrivers.com
> > > >
> > > > -----Original Message-----
> > > > From: xxxxx@lists.osr.com
> > > > [mailto:xxxxx@lists.osr.com]On Behalf Of Hassan Khan
> > > > Sent: Wednesday, April 18, 2001 4:33 PM
> > > > To: NT Developers Interest List
> > > > Subject: [ntdev] basic question
> > > >
> > > > The question is why, in layered drivers structure, everything has to
be
> > > > passed
> > > > via IRPs ? Why is it not recommended for one driver to export
functions
> > > > which
> > > > can be used by lower/other drivers ? What is the danger here ?
> > > >
> > > > regards,
> > > > Hassan
> > > >
> >
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@acm.org
> 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

If you look at the ‘classpnp’ sample in the DDK you will find just about
everything you need to know about how to build and use an export driver. An
EXPORT_DRIVER is simply a kernel dynamic link library. Actually ALL nt
kernel drivers are kernel dlls, EXPORT_DRIVERS export functions, allowing
other kernel components to link against their external functions.

There are some issues you need to be aware of, such as your client drivers
will automatically load the export driver if it isn’t currently loaded, and
in that case the export driver’s DriverEntry will NOT be called. If you
drivers are PnP managed drivers, load order can be a major headache.

Mark Roddy
Windows 2000/NT Consultant
Hollis Technology Solutions
xxxxx@hollistech.com
603 321 1032
www.hollistech.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Dong Xun
Sent: Thursday, April 19, 2001 1:56 PM
To: NT Developers Interest List
Subject: [ntdev] RE: basic question

Hi Hassan:
I have checked the DDK and online knowledge base, no result
returns. But when I check the www.deja.com , the newsgroup:
comp.os.ms-windows.programmer.nt.kernel-mode , I did find
something useful.
Please try it yourself.
It seems that once you define the EXPORT_DRIVER macro in your
SOURCES file, all of your functions could be called from other
drivers. This
is a pretty new idea and I haven’t tried it yet. If you got some
idea on how
this works, please post it here to share with us.
Also could you mail me a copy of the file you mentioned
privately to
xxxxx@advantech.com.cn ? Thanks in advance.

Hope it help
Alex

Advantech , R&D Center, Beijing
xxxxx@advantech.com.cn

----- Original Message -----
From: “Hassan Khan”
> To: “NT Developers Interest List”
> Sent: Wednesday, April 18, 2001 7:09 PM
> Subject: [ntdev] RE: basic question
>
>
> > Hi Dong,
> >
> > As the article (Driver to Driver communication) states you can store a
> > function’s address in the shared context just like anything else. And as
> long
> > as you ‘know’ the prototype you can safely call that function using that
> > address ( talking in terms of C ).
> >
> > But looking into the DDK I found that there is something thats called
> > EXPORT_DRIVER (TARGETTYPE=EXPORT_DRIVER in the sources file ) which
> export
> > functions to other kernel-mode drivers …probably Ndis.sys is one such
> > example. I don’t know yet how do you actually export functions in this
> type of
> > target. May be some .def file. If anybody knows about this method please
> help.
> >
> > Regards,
> > Hassan
> >
> >
> > Dong Xun wrote:
> >
> > > Hi Hassan:
> > > When you talk about the ‘shared context’, I think it’s a data
> structure
> > > instead of some exported function if you write in C. In my 3-layer
> driver,
> > > which is like this:
> > > Serial Driver
> > > Filter
> > > Bus Extender Driver
> > > I want to get the bus slot from serial driver, I have two choices: one
> is
> > > use INTERNAL_IOCONTROL which allow drivers to talk to each other, the
> other
> > > choice, the one I choose, is to get a pointer to the Bus Extender’s
> Device
> > > Extension in Serial Driver’s Device Extension . Then you can reference
> the
> > > bus information simply by query the linked list. The code looks like
> this:
> > > DeviceData->SlotIndex =
> > >
> ((PPDO_DEVICE_DATA)DeviceData->UnderlyingPDO->DeviceExtension)->SlotIndex;
> > > All you need to do is to store pointers to lower device’s device
> extension
> > > when creating the upper layered device.
> > >
> > > HIH
> > >
> > > Alex Dong
> > > Advantech, R&D Center, Beijing
> > > xxxxx@advantech.com.cn
> > >
> > > ----- Original Message -----
> > > From: “Hassan Khan”
> > > To: “NT Developers Interest List”
> > > Sent: Wednesday, April 18, 2001 4:28 PM
> > > Subject: [ntdev] RE: basic question
> > >
> > > > Thats right. But it seems to me to be the only reason. I just came
> > > across
> > > > an NT Insider article ‘Driver to Driver communication’ ,
> which kind of
> > > > encourage using ‘shared context’ between drivers. Basically a
> > > > non-IRP approach. Conclusion I am making here is (I could be wrong)
> if
> > > you
> > > > are sure that there will never be a need for any filter
> driver because
> you
> > > > are providing all the layers you need for this kind of
> device then its
> > > much
> > > > efficient to use your own communication method rather than sending
> your
> > > data
> > > > to NT Kernel first each time you want to send it to lower/other
> drivers in
> > > > the hierarchy.
> > > >
> > > > regards,
> > > > Hassan
> > > >
> > > > Pete Scott wrote:
> > > >
> > > > > One of the more basic rules you would be breaking is when a driver
> is
> > > > > layered between you and the driver you talk directly to, the ‘in
> > > between’
> > > > > driver would never see any of the requests passed down the stack.
> This
> > > is
> > > > > only one issue, there are many.
> > > > >
> > > > > Peter Scott
> > > > > xxxxx@KernelDrivers.com
> > > > > http://www.KernelDrivers.com
> > > > >
> > > > > -----Original Message-----
> > > > > From: xxxxx@lists.osr.com
> > > > > [mailto:xxxxx@lists.osr.com]On Behalf Of Hassan Khan
> > > > > Sent: Wednesday, April 18, 2001 4:33 PM
> > > > > To: NT Developers Interest List
> > > > > Subject: [ntdev] basic question
> > > > >
> > > > > The question is why, in layered drivers structure,
> everything has to
> be
> > > > > passed
> > > > > via IRPs ? Why is it not recommended for one driver to export
> functions
> > > > > which
> > > > > can be used by lower/other drivers ? What is the danger here ?
> > > > >
> > > > > regards,
> > > > > Hassan
> > > > >
> > >
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@advantech.com.cn
> > To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@wattanuck.mv.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

> The question is why, in layered drivers structure, everything has to be
passed

via IRPs ? Why is it not recommended for one driver to export functions
which
can be used by lower/other drivers ? What is the danger here ?

Having an IOCTL which will return the table of the function pointers to the
upper driver is OK.
WDM’s IRP_MN_QUERY_INTERFACE is a kind of such thing.

The only problem is that the functionality provided by these functions will
not be accessible from user mode - the real IRP path is needed for user
mode.

Max


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

2000 and XP add another wrinkle to the ability of drivers to communicate
with each other. You can register an interface GUID in a driver and then
allow attaching drivers to “open” and receive a pointer to this interface.
Within that interface may be shared variables as well as function calls.
This is very similar to exporting an interface via the linker, but removes
the dependency of a driver having to be re-linked because the exporting
driver was re-built. Of course if the interface changes then all divers
using it need to be rebuilt.

Gary

-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
Sent: Thursday, April 19, 2001 4:26 AM
To: NT Developers Interest List
Subject: [ntdev] Re: basic question

The question is why, in layered drivers structure,
everything has to be
passed
> via IRPs ? Why is it not recommended for one driver to
export functions
which
> can be used by lower/other drivers ? What is the danger
here ?

Having an IOCTL which will return the table of the function
pointers to the
upper driver is OK.
WDM’s IRP_MN_QUERY_INTERFACE is a kind of such thing.

The only problem is that the functionality provided by these
functions will
not be accessible from user mode - the real IRP path is
needed for user
mode.

Max


You are currently subscribed to ntdev as:
xxxxx@delphieng.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

Hi Don:
Then on which volume of the NT Insider I could find the article
you’ve mentioned? Or could you give out the link to the article?

Thanx.
Alex
----- Original Message -----
From: “Don Burn”
To: “NT Developers Interest List”
Sent: Thursday, April 19, 2001 5:00 AM
Subject: [ntdev] RE: basic question

> There is an article in the NT Insider that shows how to
> develop an EXPORT_DRIVER. The thing to realize
> with all these approaches is that “NEVER USE A
> SPECIAL MECHANISM IF THE STANDARD
> APPROACH WORKS!”.
>
> I have built drivers that share a function block or
> export routines, but in all cases I was in need of functionality
> closer to a Class driver. I had a set of functionality
> that was common to a set of devices, and another
> driver that supported a specific interface. The last thing
> you want to do is think “gee I can make my own write
> routine that my upper level driver will use”.
>
> Like all work in the kernel it is a matter of tradeoffs, but
> stick to the basics if you can. Especially if someone may
> want to submit your driver to WHQL for testing one
> day.
>
> Don Burn
> Windows 2000 Device Driver and Filesystem consulting
>
>
>
> ----- Original Message -----
> From: “Hassan Khan”
> To: “NT Developers Interest List”
> Sent: Wednesday, April 18, 2001 10:09 PM
> Subject: [ntdev] RE: basic question
>
>
> > Hi Dong,
> >
> > As the article (Driver to Driver communication) states you can store a
> > function’s address in the shared context just like anything else. And as
> long
> > as you ‘know’ the prototype you can safely call that function using that
> > address ( talking in terms of C ).
> >
> > But looking into the DDK I found that there is something thats called
> > EXPORT_DRIVER (TARGETTYPE=EXPORT_DRIVER in the sources file ) which
> export
> > functions to other kernel-mode drivers …probably Ndis.sys is one such
> > example. I don’t know yet how do you actually export functions in this
> type of
> > target. May be some .def file. If anybody knows about this method please
> help.
> >
> > Regards,
> > Hassan
> >
> >
> > Dong Xun wrote:
> >
> > > Hi Hassan:
> > > When you talk about the ‘shared context’, I think it’s a data
> structure
> > > instead of some exported function if you write in C. In my 3-layer
> driver,
> > > which is like this:
> > > Serial Driver
> > > Filter
> > > Bus Extender Driver
> > > I want to get the bus slot from serial driver, I have two choices: one
> is
> > > use INTERNAL_IOCONTROL which allow drivers to talk to each other, the
> other
> > > choice, the one I choose, is to get a pointer to the Bus Extender’s
> Device
> > > Extension in Serial Driver’s Device Extension . Then you can reference
> the
> > > bus information simply by query the linked list. The code looks like
> this:
> > > DeviceData->SlotIndex =
> > >
> ((PPDO_DEVICE_DATA)DeviceData->UnderlyingPDO->DeviceExtension)->SlotIndex;
> > > All you need to do is to store pointers to lower device’s device
> extension
> > > when creating the upper layered device.
> > >
> > > HIH
> > >
> > > Alex Dong
> > > Advantech, R&D Center, Beijing
> > > xxxxx@advantech.com.cn
> > >
> > > ----- Original Message -----
> > > From: “Hassan Khan”
> > > To: “NT Developers Interest List”
> > > Sent: Wednesday, April 18, 2001 4:28 PM
> > > Subject: [ntdev] RE: basic question
> > >
> > > > Thats right. But it seems to me to be the only reason. I just came
> > > across
> > > > an NT Insider article ‘Driver to Driver communication’ , which kind
of
> > > > encourage using ‘shared context’ between drivers. Basically a
> > > > non-IRP approach. Conclusion I am making here is (I could be wrong)
> if
> > > you
> > > > are sure that there will never be a need for any filter driver
because
> you
> > > > are providing all the layers you need for this kind of device then
its
> > > much
> > > > efficient to use your own communication method rather than sending
> your
> > > data
> > > > to NT Kernel first each time you want to send it to lower/other
> drivers in
> > > > the hierarchy.
> > > >
> > > > regards,
> > > > Hassan
> > > >
> > > > Pete Scott wrote:
> > > >
> > > > > One of the more basic rules you would be breaking is when a driver
> is
> > > > > layered between you and the driver you talk directly to, the ‘in
> > > between’
> > > > > driver would never see any of the requests passed down the stack.
> This
> > > is
> > > > > only one issue, there are many.
> > > > >
> > > > > Peter Scott
> > > > > xxxxx@KernelDrivers.com
> > > > > http://www.KernelDrivers.com
> > > > >
> > > > > -----Original Message-----
> > > > > From: xxxxx@lists.osr.com
> > > > > [mailto:xxxxx@lists.osr.com]On Behalf Of Hassan Khan
> > > > > Sent: Wednesday, April 18, 2001 4:33 PM
> > > > > To: NT Developers Interest List
> > > > > Subject: [ntdev] basic question
> > > > >
> > > > > The question is why, in layered drivers structure, everything has
to
> be
> > > > > passed
> > > > > via IRPs ? Why is it not recommended for one driver to export
> functions
> > > > > which
> > > > > can be used by lower/other drivers ? What is the danger here ?
> > > > >
> > > > > regards,
> > > > > Hassan
> > > > >
> > >
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@acm.org
> > To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@advantech.com.cn
> 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

The article is at http://www.osr.com/ntinsider/1997/krndll.htm.

Don Burn
Windows 2000 Device Driver and Filesystem consulting

----- Original Message -----
From: “Dong Xun”
To: “NT Developers Interest List”
Sent: Friday, April 20, 2001 11:49 AM
Subject: [ntdev] RE: basic question

> Hi Don:
> Then on which volume of the NT Insider I could find the article
> you’ve mentioned? Or could you give out the link to the article?
>
> Thanx.
> Alex
> ----- Original Message -----
> From: “Don Burn”
> To: “NT Developers Interest List”
> Sent: Thursday, April 19, 2001 5:00 AM
> Subject: [ntdev] RE: basic question
>
>
> > There is an article in the NT Insider that shows how to
> > develop an EXPORT_DRIVER. The thing to realize
> > with all these approaches is that “NEVER USE A
> > SPECIAL MECHANISM IF THE STANDARD
> > APPROACH WORKS!”.
> >
> > I have built drivers that share a function block or
> > export routines, but in all cases I was in need of functionality
> > closer to a Class driver. I had a set of functionality
> > that was common to a set of devices, and another
> > driver that supported a specific interface. The last thing
> > you want to do is think “gee I can make my own write
> > routine that my upper level driver will use”.
> >
> > Like all work in the kernel it is a matter of tradeoffs, but
> > stick to the basics if you can. Especially if someone may
> > want to submit your driver to WHQL for testing one
> > day.
> >
> > Don Burn
> > Windows 2000 Device Driver and Filesystem consulting
> >
> >
> >
> > ----- Original Message -----
> > From: “Hassan Khan”
> > To: “NT Developers Interest List”
> > Sent: Wednesday, April 18, 2001 10:09 PM
> > Subject: [ntdev] RE: basic question
> >
> >
> > > Hi Dong,
> > >
> > > As the article (Driver to Driver communication) states you can store a
> > > function’s address in the shared context just like anything else. And
as
> > long
> > > as you ‘know’ the prototype you can safely call that function using
that
> > > address ( talking in terms of C ).
> > >
> > > But looking into the DDK I found that there is something thats called
> > > EXPORT_DRIVER (TARGETTYPE=EXPORT_DRIVER in the sources file ) which
> > export
> > > functions to other kernel-mode drivers …probably Ndis.sys is one
such
> > > example. I don’t know yet how do you actually export functions in this
> > type of
> > > target. May be some .def file. If anybody knows about this method
please
> > help.
> > >
> > > Regards,
> > > Hassan
> > >
> > >
> > > Dong Xun wrote:
> > >
> > > > Hi Hassan:
> > > > When you talk about the ‘shared context’, I think it’s a data
> > structure
> > > > instead of some exported function if you write in C. In my 3-layer
> > driver,
> > > > which is like this:
> > > > Serial Driver
> > > > Filter
> > > > Bus Extender Driver
> > > > I want to get the bus slot from serial driver, I have two choices:
one
> > is
> > > > use INTERNAL_IOCONTROL which allow drivers to talk to each other,
the
> > other
> > > > choice, the one I choose, is to get a pointer to the Bus Extender’s
> > Device
> > > > Extension in Serial Driver’s Device Extension . Then you can
reference
> > the
> > > > bus information simply by query the linked list. The code looks
like
> > this:
> > > > DeviceData->SlotIndex =
> > > >
> >
((PPDO_DEVICE_DATA)DeviceData->UnderlyingPDO->DeviceExtension)->SlotIndex;
> > > > All you need to do is to store pointers to lower device’s device
> > extension
> > > > when creating the upper layered device.
> > > >
> > > > HIH
> > > >
> > > > Alex Dong
> > > > Advantech, R&D Center, Beijing
> > > > xxxxx@advantech.com.cn
> > > >
> > > > ----- Original Message -----
> > > > From: “Hassan Khan”
> > > > To: “NT Developers Interest List”
> > > > Sent: Wednesday, April 18, 2001 4:28 PM
> > > > Subject: [ntdev] RE: basic question
> > > >
> > > > > Thats right. But it seems to me to be the only reason. I just
came
> > > > across
> > > > > an NT Insider article ‘Driver to Driver communication’ , which
kind
> of
> > > > > encourage using ‘shared context’ between drivers. Basically a
> > > > > non-IRP approach. Conclusion I am making here is (I could be
wrong)
> > if
> > > > you
> > > > > are sure that there will never be a need for any filter driver
> because
> > you
> > > > > are providing all the layers you need for this kind of device then
> its
> > > > much
> > > > > efficient to use your own communication method rather than sending
> > your
> > > > data
> > > > > to NT Kernel first each time you want to send it to lower/other
> > drivers in
> > > > > the hierarchy.
> > > > >
> > > > > regards,
> > > > > Hassan
> > > > >
> > > > > Pete Scott wrote:
> > > > >
> > > > > > One of the more basic rules you would be breaking is when a
driver
> > is
> > > > > > layered between you and the driver you talk directly to, the ‘in
> > > > between’
> > > > > > driver would never see any of the requests passed down the
stack.
> > This
> > > > is
> > > > > > only one issue, there are many.
> > > > > >
> > > > > > Peter Scott
> > > > > > xxxxx@KernelDrivers.com
> > > > > > http://www.KernelDrivers.com
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: xxxxx@lists.osr.com
> > > > > > [mailto:xxxxx@lists.osr.com]On Behalf Of Hassan Khan
> > > > > > Sent: Wednesday, April 18, 2001 4:33 PM
> > > > > > To: NT Developers Interest List
> > > > > > Subject: [ntdev] basic question
> > > > > >
> > > > > > The question is why, in layered drivers structure, everything
has
> to
> > be
> > > > > > passed
> > > > > > via IRPs ? Why is it not recommended for one driver to export
> > functions
> > > > > > which
> > > > > > can be used by lower/other drivers ? What is the danger here ?
> > > > > >
> > > > > > regards,
> > > > > > Hassan
> > > > > >
> > > >
> > >
> > >
> > > —
> > > You are currently subscribed to ntdev as: xxxxx@acm.org
> > > To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@advantech.com.cn
> > To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@acm.org
> 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