Daniel> There are only two stacks involved, the normal kernel
Daniel> stack and your new ndis stack. You save ESP of the kernel
Daniel> stack at the base of the ndis stack. When the Windows
Daniel> code calls your api, you get the ndis ESP, load the kernel
Daniel> ESP from the base of the ndis stack, push the ndis ESP so
Daniel> you can get back to the ndis code later, and continue on
Daniel> your merry way.
[...]
Daniel> You will allocate your own stack once on driver
Daniel> initialization.
I'm not quite sure it's this trivial. Obviously there are more than
two stacks involved, since there is more than one kernel stack! (One
per task plus IRQ stacks) This is more than just a theoretical
problem. It seems entirely possible that more than one task could
be in the driver, and clearly they each need their own stack.
So it's going to be at least a little harder than allocating a single
stack for NDIS use when the driver starts up.
I personally like the idea raised elsewhere in this thread of running
the Windows driver in userspace by proxying interrupts, PCI access,
etc. That seems more robust and probably allows some cool reverse
engineering hacks.
- R.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
