Hi There,
I have been working on windows drivers for some time now. Just got a chance to work on linux kernel mode component. I just found out that linux kernel keeps a table called Kernel Symbol table and the unresolved symbols are resolved using this table when the driver with some unresolved symbol loads. This allows any kernel mode component to call any other kernel mode component. This is cool.
This makes me wonder how would a kernel mode function driver in windows call another kernel mode driver (let’s say possibly in different driver stack) in windows. What about miniport drivers? For example if I have to implement let’s say scsi over IP then I will need to have a NDIS driver and a SCSI/STORPORT miniport driver. They will need to communicate with each other. How is this achieved?
I have been working on windows drivers for some time now. Just
got a chance to work on linux kernel mode component. I just found out
that linux kernel keeps a table called Kernel Symbol table and the
unresolved symbols are resolved using this table when the driver with
some unresolved symbol loads. This allows any kernel mode component to
call any other kernel mode component. This is cool.
Not really. That forces a very tight coupling between the modules, and
makes it almost impossible to make a Linux kernel module binary that
works with more than one version of the kernel.
Windows solves this problem by DLLs. The only difference is that I need
to know which library it’s in.
This makes me wonder how would a kernel mode function driver in
windows call another kernel mode driver (let’s say possibly in
different driver stack) in windows. What about miniport drivers? For
example if I have to implement let’s say scsi over IP then I will need
to have a NDIS driver and a SCSI/STORPORT miniport driver. They will
need to communicate with each other. How is this achieved?
If you really want linkage, you can use a kernel DLL. However, there
are many, many ways of doing inter-driver communication that are
substantially better than either the Linux kernel symbol table or kernel
DLLs. Driver interfaces are one very good example. Callbacks. Raw
PDOs. It all depends on what you need to do.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
There are several ways that two drivers can communicate with eah other:
Irp’s
Imports/exports
Device interfaces (see wdk)
Passing a table of function pointers
Mm
On Aug 18, 2010 9:13 PM, “Ajitabh Saxena” wrote:
Hi There,
I have been working on windows drivers for some time now. Just got a chance to work on linux kernel mode component. I just found out that linux kernel keeps a table called Kernel Symbol table and the unresolved symbols are resolved using this table when the driver with some unresolved symbol loads. This allows any kernel mode component to call any other kernel mode component. This is cool.
This makes me wonder how would a kernel mode function driver in windows call another kernel mode driver (let?s say possibly in different driver stack) in windows. What about miniport drivers? For example if I have to implement let?s say scsi over IP then I will need to have a NDIS driver and a SCSI/STORPORT miniport driver. They will need to communicate with each other. How is this achieved?
Yes, I am using Device Interface and passing a table of function pointers. Both are work fine.
Thanks
Wayne
Date: Wed, 18 Aug 2010 21:18:04 -0400
Subject: Re: [ntdev] Communication between two drivers.
From: xxxxx@gmail.com
To: xxxxx@lists.osr.com
There are several ways that two drivers can communicate with eah other:
Irp’s
Imports/exports
Device interfaces (see wdk)
Passing a table of function pointers
Mm
On Aug 18, 2010 9:13 PM, “Ajitabh Saxena” wrote:
Hi There,
I have been working on windows drivers for some time now. Just got a chance to work on linux kernel mode component. I just found out that linux kernel keeps a table called Kernel Symbol table and the unresolved symbols are resolved using this table when the driver with some unresolved symbol loads. This allows any kernel mode component to call any other kernel mode component. This is cool.
This makes me wonder how would a kernel mode function driver in windows call another kernel mode driver (let¡¯s say possibly in different driver stack) in windows. What about miniport drivers? For example if I have to implement let¡¯s say scsi over IP then I will need to have a NDIS driver and a SCSI/STORPORT miniport driver. They will need to communicate with each other. How is this achieved?
Any links/docs will be great help.
Thanks,
n Ajitabh
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Wayne Gong
Sent: Wednesday, August 18, 2010 10:47 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Communication between two drivers.
Yes, I am using Device Interface and passing a table of function pointers.
Both are work fine.
Thanks
Wayne
Date: Wed, 18 Aug 2010 21:18:04 -0400
Subject: Re: [ntdev] Communication between two drivers.
From: xxxxx@gmail.com
To: xxxxx@lists.osr.com
There are several ways that two drivers can communicate with eah other:
Irp’s
Imports/exports
Device interfaces (see wdk)
Passing a table of function pointers
Mm
On Aug 18, 2010 9:13 PM, “Ajitabh Saxena” wrote:
Hi There,
I have been working on windows drivers for some time now. Just got a chance to work on linux kernel mode component. I just found out that linux kernel keeps a table called Kernel Symbol table and the unresolved symbols are resolved using this table when the driver with some unresolved symbol loads. This allows any kernel mode component to call any other kernel mode component. This is cool.
This makes me wonder how would a kernel mode function driver in windows call another kernel mode driver (let’s say possibly in different driver stack) in windows. What about miniport drivers? For example if I have to implement let’s say scsi over IP then I will need to have a NDIS driver and a SCSI/STORPORT miniport driver. They will need to communicate with each other. How is this achieved?
>kernel mode component. I just found out that linux kernel keeps a table called Kernel Symbol table and
the unresolved symbols are resolved using this table when the driver with some unresolved symbol
loads. This allows any kernel mode component to call any other kernel mode component. This is cool.
This only means that Linus personally had no notion of encapsulation when writing the old Linux kernel.
Nothing cool. Changes in the kernel internals require them to do massive rewrites of many driver stacks.
SCSI/STORPORT miniport driver. They will need to communicate with each other. How is this
achieved?
Lots of ways like PnP query interface, export drivers, PnP bus drivers with 2 child PDOs - network and SCSI, IoGetDeviceObjectPointer (possibly after IoGetDeviceInterfaces) and so on.
