Re: RFC: i386: kill !4KSTACKS

[Daniel Phillips]

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