From: Dong Xun [Dong.Xun@advantech.com.cn]
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
Dong.Xun@advantech.com.cn ? Thanks in advance.

Hope it help
Alex

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

----- Original Message -----
From: "Hassan Khan" <Hassan.Khan@trimedia.com>
To: "NT Developers Interest List" <ntdev@lists.osr.com>
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
> > Dong.Xun@advantech.com.cn
> >
> > ----- Original Message -----
> > From: "Hassan Khan" <Hassan.Khan@trimedia.com>
> > To: "NT Developers Interest List" <ntdev@lists.osr.com>
> > 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
> > > > PScott@KernelDrivers.com
> > > > http://www.KernelDrivers.com
> > > >
> > > > -----Original Message-----
> > > > From: bounce-ntdev-3997@lists.osr.com
> > > > [mailto:bounce-ntdev-3997@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: Dong.Xun@advantech.com.cn
> To unsubscribe send a blank email to leave-ntdev-247T@lists.osr.com


---
You are currently subscribed to ntdev as: GlennEverhart@FirstUSA.com
To unsubscribe send a blank email to leave-ntdev-247T@lists.osr.com