Re: RFC: i386: kill !4KSTACKS

[Roland Dreier]

    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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/