On Tuesday 06 September 2005 13:23, Giridhar Pemmasani wrote:
> Jan Kiszka wrote:
> > The only way I see is to switch stacks back on ndiswrapper API entry.
> > But managing all those stacks correctly is challenging,
There are only two stacks involved, the normal kernel stack and your new ndis
stack. You save ESP of the kernel stack at the base of the ndis stack. When
the Windows code calls your api, you get the ndis ESP, load the kernel ESP
from the base of the ndis stack, push the ndis ESP so you can get back to the
ndis code later, and continue on your merry way.
> > as you will likely not want to create a new stack on each switching
> > point...
You will allocate your own stack once on driver initialization.
> This is what I had in mind before I saw this thread here. I, in fact, did
> some work along those lines, but it is even more complicated than you
> mentioned here: Windows uses different calling conventions (STDCALL,
> FASTCALL, CDECL) so switching stacks by copying arguments/results gets
> complicated.
I missed something there. You would switch stacks before calling the Windows
code and after the Windows code calls you (and respective returns) so you are
always in your own code when you switch, hence you know how to copy the
parameters.
> I am still hoping that Andi's approach is possible (I don't understand how
> we can make kernel see current info from private stack).
He suggested you use your own private variant of current which would
presumeably read a copy of current you stored at the bottom of your own
stack. But I don't see why your code would ever need current while you are
on the private ndis stack.
Andi, their stack will have to have a valid thread_info->task because
interrupts will use it. Out of interest, could you please explain what for?
Code like u32 stack[THREAD_SIZE/sizeof(u32)] is violated by a different sized
stack, but apparently not in any way that matters.
By the way, I use ndis_wrapper, thanks a lot you guys!
Regards,
Daniel
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |