When we call IoSkipCurrentIoStackLocation the system’s IO_STACK_LOCATION array pointer is modified so that when the current driver calls the next lower driver , that driver receives the same IO_STACK_LOCATION that the current driver revieved.
This is done to pass the IRP to the next-lower driver. But the next lower driver must have had its own IO_STACK_LOCATION before calling IoSkipCurrentIoStackLocation. So does the next-lower drivers own IO_STACK_LOCATION get replaced or overwritten. Is it lost?
If yes then how can the next-lower driver access its own IO_STACK_LOCATION?
IoSkipCurrentIoStackLocation is there for when you are not modifying the
IRP or wanting to catch completion. Basically, the call forces a reuse of
the stack location for the next driver, as if your driver was not present.
A lot of bugs in the past were people attempting to copy the stack location
down for a simple passthru and messing up which would cause a crash. This
macro is there to make this common case painless.
wrote in message news:xxxxx@ntdev… > When we call IoSkipCurrentIoStackLocation the system’s IO_STACK_LOCATION > array pointer is modified so that when the current driver calls the next > lower driver , that driver receives the same IO_STACK_LOCATION that the > current driver revieved. > This is done to pass the IRP to the next-lower driver. But the next lower > driver must have had its own IO_STACK_LOCATION before calling > IoSkipCurrentIoStackLocation. So does the next-lower drivers own > IO_STACK_LOCATION get replaced or overwritten. Is it lost? > If yes then how can the next-lower driver access its own > IO_STACK_LOCATION? > > Thanks in advance, > Anand >
Please, don’t send the same letter for me.
Thank you very much.
On 5/28/07, xxxxx@wipro.com wrote: > > When we call IoSkipCurrentIoStackLocation the system’s IO_STACK_LOCATION > array pointer is modified so that when the current driver calls the next > lower driver , that driver receives the same IO_STACK_LOCATION that the > current driver revieved. > This is done to pass the IRP to the next-lower driver. But the next lower > driver must have had its own IO_STACK_LOCATION before calling > IoSkipCurrentIoStackLocation. So does the next-lower drivers own > IO_STACK_LOCATION get replaced or overwritten. Is it lost? > If yes then how can the next-lower driver access its own > IO_STACK_LOCATION? > > Thanks in advance, > Anand > > — > Questions? First check the Kernel Driver FAQ at > http://www.osronline.com/article.cfm?id=256 > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer >
What are you trying to say? Why are you saying it so many times?
“Tran Huy Ky” wrote in message news:xxxxx@ntdev… Please, don’t send the same letter for me. Thank you very much.
On 5/28/07, xxxxx@wipro.com < xxxxx@wipro.com> wrote: When we call IoSkipCurrentIoStackLocation the system’s IO_STACK_LOCATION array pointer is modified so that when the current driver calls the next lower driver , that driver receives the same IO_STACK_LOCATION that the current driver revieved. This is done to pass the IRP to the next-lower driver. But the next lower driver must have had its own IO_STACK_LOCATION before calling IoSkipCurrentIoStackLocation. So does the next-lower drivers own IO_STACK_LOCATION get replaced or overwritten. Is it lost? If yes then how can the next-lower driver access its own IO_STACK_LOCATION?
This macro is to replace the stack location copy with a pointer shift. It’s
only practical difference from IoCopyCurrentIrpStackLocationToNext is that you cannot register a completion routine with skip.
Skip is the same as IoCopyCurrentIrpStackLocationToNext without a
completion routine, so, use IoCopyCurrentIrpStackLocationToNext only if you
need a completion routine.
wrote in message news:xxxxx@ntdev… > When we call IoSkipCurrentIoStackLocation the system’s IO_STACK_LOCATION array pointer is modified so that when the current driver calls the next lower driver , that driver receives the same IO_STACK_LOCATION that the current driver revieved. > This is done to pass the IRP to the next-lower driver. But the next lower driver must have had its own IO_STACK_LOCATION before calling IoSkipCurrentIoStackLocation. So does the next-lower drivers own IO_STACK_LOCATION get replaced or overwritten. Is it lost? > If yes then how can the next-lower driver access its own IO_STACK_LOCATION? > > Thanks in advance, > Anand >
I do not see any duplicates, but I switched to using NNTP a long time ago.
In any case replying to a message will not ensure that problems with the
list server are corrected. He should follow the link given on the last line
of the main page you see after clicking on “List Sever / Forum”. I see it
when I am automatically logged in, just in case viewing without logging in
does not show the same page. I see they now offer RSS and web access, so it
is possible that changes have caused multiple copies of a message to be
seen. It may only occur when someone posts using one method, so from the
lines at the bottom, I suspect it may be email. I only use NNTP, so if you
haven’t seen duplicate posts from me, then that method works.
“Justin Schoenwald” wrote in message news:xxxxx@ntdev… > At 12:29 PM 5/28/2007, you wrote: >>What are you trying to say? Why are you saying it so many times? >> >>Please, don’t send the same letter for me. >>Thank you very much. > > I think this may be a plea to stop duplicates from this list. I’ve been > getting a lot of duplicated posts myself. > > > > >
If I got it right, you are not happy about the fact that you receive a copy of every post that we make
here. If this is what you mean by your posts, you should just change your OSR account settings, i.e. unsubsribe from the mailing list…
What confuses noobs about this is that they often fail to realize that IRP stack locations aren’t “dedicated” to particular devices/drivers. The I/O Stack is, quite literally, just a stack. Each device that handles an IRP uses the next stack location in the IRP’s I/O Stack and when stack locations run out, Bad Things ™ can happen. Soooo… the idea behind this call is to allow a driver to say “I don’t want to handle this IRP, I don’t care about this IRP, I just wanna pass it along to the next device.”
In terms of the architectural meaning behind the function, I’ve never understood it either… but talking to the responsible devs (multiple times, years ago) has gotten me nowhere. Obviously, I fail to appreciate the beauty of merely decrementing the IO_STACK_LOCATION pointer and leaving whatever crap happens to be in the IO_STACK_LOCATION there for the next guy.
Regarding the LIST SERVER:
IF anybody’s getting duplicate messages, it’s almost certainly their settings and not the list server. The only change we’ve made to the list server in many months is to disallow web-based postings to threads that are “old” (as we had a new member or two with a penchant for trying to revive threads long-dead).
Anytime you have a listserver problem, and you’ve thoroughly researched and exhausted your own remedies (checked your OSR Online settings, ensured you haven’t set up two OSR Online accounts with email addresses that forward to your own – don’t laugh, it happens a lot – etc, etc) then email xxxxx@osr.com with the details of your problem.