Hi,
In out solution we need to have one driver which is not attched to
any hardware but it will manage different functional drivers accessing
the same hardware. like below

DRIVER A - driver which is not attached to any hardware
DRIVER B1 - Function driver 1 (say NDIS miniport)
DRIVER B2 - Function driver 2 (say USB)

DRIVER A has to be loaded first as pre-requisite for DRIVER Bx
loading.
DRIVER B1 and B2 will access same hardware.

Questions
- Is it possible to have this architecture?
- How to communicate between Driver A and Driver Bx? is it thru IRP?
any other standard method?

Thanks,
Raman

Several questions, when you say the same hardware, do you mean multiple
functions in a single device, or all the same funtion? Can B1 and B2 both
be present?

This is not a typical Windows driver model you are proposing. Typically A
would be a BUS driver and would split the hardware so B1 and B2 could use
it. If these are multiple functions, then A would split the functions
providing the resources for each function to the appropriate driver. If
they are one function or sharing resources (such as an interrupt) then A
would handle the access to the shared functions. If you wanted only one
device active at a time, A would provide the resources to the desired
driver, and when you wanted to swap it would remove that device, and add
the other device providing the functions to the second driver.

There is a lot about bus drivers in the WDK, and the toaster sample gives
you a piece of source to start with.

--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply


"jhon" <jhansi_raman@lycos.com> wrote in message
news:1182193562.492182.65000@g37g2000prf.googlegro ups.com...

Thanks for the reply DON,
Let me explain in more detail.

We have multi-function hardware and it's possible to have both
functions enabled at same time.
To ensure code re-usability and isolating the code to make porting
easy across platforms we are dividing architecture as follows (I
forgot to add one driver in my origianl question)
WE will have one COMMON driver which will access the hardware and
provide custom IOCTL for other drivers to use it.
Other drivers (DRIVER Bx and DRIVER A) can use that IOCTL and access
the hardware.
In addition, DRIVER A will manage connection references betwenn
DRIVER B1 , DRIVER B2 .. etc.
DRIVER B1, B2 will have specific functionality for their
implementations like NDIS miniport, USB, etc.
DRIVER A will just act as midlle person between DRIVER B1, B2, etc.

So, when we insert our hardware it will prompt for driver for
function 1 then we point to DRIVER B1 INF and it will load COMMON
DRIVER (for hardware access) and DRIVER A.
When OS prompts driver for function 2, we will point to DRIVER B2
and this time it will use existing loaded COMMON DRIVER and DRIVER A.

Is this possible to achieve?

[We thought about using Kernel DLL but then data segement will not be
shared]

Thanks,
Raman.

On Jun 18, 12:17 pm, "Don Burn" <b...@stopspam.windrvr.com> wrote:

Comments inline:

"jhon" <jhansi_raman@lycos.com> wrote in message
news:1182196409.038352.69490@n2g2000hse.googlegrou ps.com...
Forget about porting across multiple platforms, unless you are extremely
experienced in Windows and from your questions you are not, this is a
guarantee of disaster or at least an unreliable and slow driver.

This should be a bus driver, look at device interfaces rather than IOCTL's

Driver A does not access hardware, but does use the IOCTL's is this
correct?

So why do you have driver A? Why do you need a middle driver? This seems
like a bloated design, for no reason.

would have had. The bus driver is loaded when the hardware comes in, then
it can create PDO's for B1 and B2 which will trigger their INF files and
load them.

data segment. But using a kernel mode DLL is not the right thing here.
Follow the windows architecture and be safe.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

Hi Don,
Thanks for your suggestions on the design and we will try to make it
that way.
but few other questions on possiblities (may not be efficient but
possible or not)
A. Can we have one driver (which is not attached to any hardware,
it's just exposing some functions) loaded as dependency of another
drivers? (using preload dependency) Basically same as Kernel dll
except its on driver stack. Is it possible to do that?
B. Is there any documentation on how to have shared data segment
using kernel DLL.

Thanks,
Raman

On Jun 18, 1:05 pm, "Don Burn" <b...@stopspam.windrvr.com> wrote:

You can for drivers, indicate that a driver depends on another driver, so
yes you can do that. The data segments of all kernel modules are shared
(i.e. two drivers using a DLL will get the same data segment in the DLL).
If you are looking to have a data area shared by multiple drivers, then use
one of the common inter-driver mechanisms (such as IOCTL or device
interface) to query one driver on where the data is returning a pointer to
it.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

"jhon" <jhansi_raman@lycos.com> wrote in message
news:1182273969.314610.187010@k79g2000hse.googlegr oups.com...

Hi Don,
few very specific questions. it would really help me if you could
answer those.
1. Can I have WDM driver DRIVER-A which has to be loaded by another
PNP driver say PNP-driver-1.
2. If another PNP driver say PNP-driver-2 loads, then it should use
already loaded DRIVER-A (using IoGetDeviceObjectPointer)
How can I achieve above? Does my DRIVER-A driver has to be non-PNP
to achieve this? or root enumerated PNP driver? or Leagacy driver? or
something else

Thanks,
Raman



On Jun 19, 10:32 am, "Don Burn" <b...@stopspam.windrvr.com> wrote:

jhon <jhansi_raman@lycos.com> wrote:
Loaded how? Kernel drivers can load kernel DLLs just like a user-mode app
can, but such a kernel DLL is neither WDM nor PnP. It doesn't have its own
device object.

A WDM/PnP driver can act like a bus driver and cause other drivers to get
loaded in the normal PnP manner as well.

Use it in what way? IoGetDeviceObjectPointer is somewhat similar to
calling CreateFile from user mode. It lets you send ioctls to an existing
device.

I suspect you are headed down the wrong path. Can you be more explicit
about exactly what you want to do?
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

The relative load order of PnP drivers is not defined, only Boot and
non-Boot notions are defined for them.

So, register the device interface in A, and wait for device interface
arrival notification in B. On such notification (rendez-vous point), call
ZwCreateFile.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

"jhon" <jhansi_raman@lycos.com> wrote in message
news:1183342415.086189.190460@q69g2000hsb.googlegr oups.com...

Thanks Maxim,
Is there a Sample example doing such thing? Also, I hope this would
work even if I have DRIVER A as non-pnp driver, please confirm.
Thanks for your help.

- Raman

On Jul 2, 4:36 am, "Maxim S. Shatskih" <m...@storagecraft.com> wrote:

Device interface requires a PnP PDO as a target.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

"jhon" <jhansi_raman@lycos.com> wrote in message
news:1183400206.911847.25010@g4g2000hsf.googlegrou ps.com...

Hi Maxim,
I am bit confused, please clarify.
Device interface requires a PnP PDO as target, does that mean
A) both drivers has to be PNP
or
B) only tartget driver which is waiting for another drivers
interface arrival has to be PNP
or
C) only source driver has to be PNP. (this wont work for me)

Thanks,
Sandip
On Jul 2, 11:21 am, "Maxim S. Shatskih" <m...@storagecraft.com> wrote: