Re: WDF storage driver is a dead-end street

On Dec 23, 6:11 am, "Don Burn" <b...@xxxxxxxxxxxxxxxxxxxx> wrote:
A couple of items I missed:

1.  Not only WHQL, but the ntldr environment for booting will not support
the additional calls so if you are not useing a BIOS solution you are hosed.

2.  Assuming you are using a BIOS solution, you might check with Microsoft
whether they would accept a Virtual Storport (based on the ISCSI model) that
Windows 2003 and Longhorn support.   If it does then you can have a storport
and then write a regular WDM or WDF driver for it to call to do the real
work.   While I have never tried it, it may be possible to use a filter of
the ATAPORT for each device and have the virtual storport communicate with
that.

--
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

"Don Burn" <b...@xxxxxxxxxxxxxxxxxxxx> wrote in message

news:OksxmmWRIHA.3916@xxxxxxxxxxxxxxxxxxxxxxx





<dwightrile...@xxxxxxxxx> wrote in message
news:c63e4023-a0d0-4710-8263-0bd64c8ecd41@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
doing the device virtualization in a single miniport which would  own
both  controllers brings me back to my original questions:

Since I will expose 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.

No, it means you have to convince the OS that the two devices you are
dealing with are one strange device.  Now getting both sets of resources
is a challenge but once there you own everything.

That means  the synchronization the OS provides around the passed-in
Controller Extension  would not be sufficient.

Why, if you have control of both devices you will have synchronization.

So again, 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 ?

They will work but not pass WHQL.

Does this get flagged in some WHQL test (and if so, where)?

There is an import test for storage that says what calls your mini-port
may do.

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.

Unless you want to messup the performance system using your own locking
API's is one of the stupidest things people can do.  Sorry, this is just a
really bad idea, that over the years has caused many products to die with
the reputation of "put on X and the whole system runs like crap".

--
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- Hide quoted text -

- Show quoted text -

Hi Don,
thanks alot for your reply. You said:

"No, it means you have to convince the OS that the two devices you
are
dealing with are one strange device."

I guess where I am getting lost is, how can I convince the OS that
there aren't two separate controllers when the bus enumerator logic
already is well-aware of that fact - I only will only get a crack at
the two cards in the first place because I will specifiy that I
support PCI Vendor&Device ID/SubVendor&Device ID of our own
proprietary card and I will also specificy that I support a standard
AHCI controller card, etc.

So it seems like by the time I'm even called at DriverEntry, etc , the
horse has left the gate so-to-speak with respect to the OS not being
aware that there are two distinct cards we are talking about - and I
will be claiming both.


>>>> That means the synchronization the OS provides around the
passed-in
>>>> Controller Extension would not be sufficient.

Why, if you have control of both devices you will have synchronization.

I guess I'm thinking in terms of the same issue as above - ie, if I
claim both cards, they will each have different adapter (ie controller
or card) extensions. Since the extension is passed in the miniport at
each of its major entry points, the locking from above the miniport
layer will protect against re-entrancy on behalf of the same extension
(or card) but will not synchronize across cards.

The issue is really what you said above - but in order to make the OS
think I have one card instead of two after it's already enumerated two
(because I can't have the resources on the respective cards unless I
say, for each one, "yes, I found the card and its mine and its
healthy).

So I need to create a virtual adapter out of two physical adapters.
And a single virtual (boot) device associated with that adapter that
will actually span both physical devices on both of the physical
adapters.

I don't think I can create a virtual adapter inside the real
miniport since that is the layer that knows about and claims the
actual distinct physical adapters. I guess it would have to be in a
filter driver or port driver or virtual miniport driver above the real
miniport.

Are "standard" filter drivers permitted between the [scsi/stor/
ata]Port and miniport drivers?

I know you said we couldn't replace any of the MS port drivers with
our own but the new idea of a virtual miniport between the real
Ataport driver and the real miniport driver sounds like it might work
if it's allowed ...

thanks alot again!
.

Relevant Pages

  • Re: Loading Unloading NDIS Intermediate Dirver
    ... Each miniport adapter must have a unique name. ... driver inserts itself between an underlying adapter and a protocol driver, ...
    (microsoft.public.windowsce.platbuilder)
  • Re: Ataptec SCSI card problem
    ... I tried to install this card debian 4.0, ubuntu 7.10, Fedora Core 8, ... Slackware 12 and I have always the same message from scsi card. ... what it looks like to me, the problem is to be found in the driver, rather ... SCSI adapter family, which means that they can be used in two modes, i.e. ...
    (comp.os.linux.hardware)
  • SMSC9118 NDIS ethernet driver, to connect LAN9115 directly to a PXA270 (no glue logic like cpld)
    ... I am trying to integrate in windows ce5.0 smsc driver for 911x family. ... adapter, then the pointer turns into a hour glass forever. ... ndisMInitializeAdapter: Miniport 0003B9C0, ... Miniport 0003B9C0, MiniBlock 0003B620, rc ...
    (microsoft.public.windowsce.embedded)
  • Re: Using a second display adapter
    ... adding a PCI adapter to a system that already ... has an AGP card. ... I am really more interested in the hardware level, not using Linux ... Console or xorg driver at all. ...
    (Debian-User)
  • Re: NetBIOS Routing
    ... of its virtual adapter instances. ... device gets plugged in our out, you simply talk to whichever miniport ... And one MUX IM driver, ... >>> In this type of setup is the mux miniport not used. ...
    (microsoft.public.development.device.drivers)