Re: WDF storage driver is a dead-end street
- From: "Don Burn" <burn@xxxxxxxxxxxxxxxxxxxx>
- Date: Fri, 21 Dec 2007 08:30:48 -0500
Krish and Dwight,
You are really attacking the problem in the wrong way. I would add a
simple disk filter (easy with WDF) that recognizes the two devices and
blocks all "normal" actions to the devices. The filters would each
register a device interface to allow access by your special device. Then
using the ramdisk sample as a base have a third driver that manages the two
devices and does the work by calling the device interfaces that the filters
applied.
This is a fairly small and constrained piece of work versus the full
blown storage stack, and takes advantage of the storage stack code for you
work. This also gives you flexibility if you need to change one of the
hardware devices.
--
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
<dwightrileyjr@xxxxxxxxx> wrote in message
news:9fd537d1-a05e-4f8e-b153-5bc26cae7a8d@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Hi Krish, Don, Maxim,
I am glad I came across this forum for asking questions - I am
actually trying to do something very similiar to what Krish is trying
to do.
I need to present two separate physical devices as one device to the
VISTA OS. I now know I have to be a miniport driver;it would be best
if I could be an ATAPORT miniport so I don't have to do SCSI-to-ATA
translation (my devices have an ATA interface).
Here is the challenging part: my two devices are not children of the
same PCI device like for example, 2 disks on a SCSI or ATA
controller.. My two devices are attached to completely separate PCI
Mass Storage Controller devices. I don't want the OS to manage them as
two devs though - I need to claim both cards, get resources mapped for
both of them, ec. but instead of exposing the two physical devices
that are attached to these controllers , expose instead a virtual disk
that actually spans both the of Mass Storage Controllers
When requests come in , I will manage the traffic and decide which
controller/device pair to forward the request to. This means I may try
to talk to completely different device than the one the OS thought
the request was actually bound for since of course the OS expects we
are stricly in the context of the first device .
That means the synchronization the OS provides around the passed-in
Controller Extension would not be sufficient.
I am worried about what will happen when I attempt to use locking/
synchronization APIs that are beyond the scope of the ataport/miniport
module ?
Does this get flagged in some WHQL test (and if so, do any of you
happen to know where)?
Are there some kernel APIs they are more forgiving of than others?
I am thinking about writing my own locking/unlockin macros in case it
turns out there is absolutely no way to use WDM APIs.
well thanks very much in advance.
Dwight
.
- Follow-Ups:
- Re: WDF storage driver is a dead-end street
- From: krish
- Re: WDF storage driver is a dead-end street
- References:
- WDF storage (IDE) stack;
- From: krish
- Re: WDF storage (IDE) stack;
- From: Don Burn
- Re: WDF storage driver is a dead-end street
- From: krish
- Re: WDF storage driver is a dead-end street
- From: krish
- Re: WDF storage driver is a dead-end street
- From: dwightrileyjr
- WDF storage (IDE) stack;
- Prev by Date: Re: WDF storage driver is a dead-end street
- Next by Date: Re: Standard/RTL/CRC C functions in STORPORT miniport drivers
- Previous by thread: Re: WDF storage driver is a dead-end street
- Next by thread: Re: WDF storage driver is a dead-end street
- Index(es):
Relevant Pages
|
|