Re: irp cloning...
From: Martin Harvey \(work\) (m.harvey_at_nospam.snellwilcox.com)
Date: 01/07/05
- Next message: M Taha Masood: "capturing all audio out reliably : DirectSound or MSVAD?"
- Previous message: Simon: "DeviceIOControl Hangs"
- In reply to: Greg Becker: "irp cloning..."
- Next in thread: Greg Becker: "Re: irp cloning..."
- Reply: Greg Becker: "Re: irp cloning..."
- Messages sorted by: [ date ] [ thread ]
Date: Fri, 7 Jan 2005 12:31:14 -0000
"Greg Becker" <greg@codeconcepts.com> wrote in message
news:ohs0b2-5pa2.ln1@gromit.codeconcepts.com...
> However, if I instruct the driver to perform mirroring, the data sent
> to the primary device is always corrupted (I am currently unable to
> verify the secondary as it is not written in the original format).
> It's probably worth admitting that while I have programmed drivers for
> Unix for many years I've only been working with NT for a month or so.
First impressions?
> I would greatly appreciate any insight into how to solve this problem
> correctly. I have scoured this list and the web for similar examples
> but haven't found anything relevant thus far.
I could be totally wrong here (I'm not a guru or anything) but my thoughts
are:
> #define CLONE_IRP(src, dst, zoffset) \
> do { \
> IO_STACK_LOCATION *srcstk, *dststk; \
> srcstk = IoGetCurrentIrpStackLocation(src); \
> dststk = IoGetCurrentIrpStackLocation(dst); \
> *dststk = *srcstk; \
This seems a trifle on the "ambitious" side to me. In particularly, there's
quite a lot of stuff in an IO_STACK_LOCATION that you might want to
consider....
For a start, just looking at copying stack locations which are on the same
stack, the DDK gives you:
#define IoCopyCurrentIrpStackLocationToNext( Irp ) { \
PIO_STACK_LOCATION irpSp; \
PIO_STACK_LOCATION nextIrpSp; \
irpSp = IoGetCurrentIrpStackLocation( (Irp) ); \
nextIrpSp = IoGetNextIrpStackLocation( (Irp) ); \
RtlCopyMemory( nextIrpSp, irpSp, FIELD_OFFSET(IO_STACK_LOCATION,
CompletionRoutine)); \
nextIrpSp->Control = 0; }
So copying the completion routine or anything after might possibly be a bad
idea, and you may need to look at the control field.
Secondly, if you're copying to/from different stacks, then you're likely to
need to be a great deal more cautious in what you overwrite - the device
object & file object pointers might not take kindly to being overwritten.
After that, how you handle the actual parameters depends on the type of IRP,
and some things may not be as re-usable as one might think...
MH.
- Next message: M Taha Masood: "capturing all audio out reliably : DirectSound or MSVAD?"
- Previous message: Simon: "DeviceIOControl Hangs"
- In reply to: Greg Becker: "irp cloning..."
- Next in thread: Greg Becker: "Re: irp cloning..."
- Reply: Greg Becker: "Re: irp cloning..."
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|