On Tue, 6 Sep 2005, 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, as you will
>> likely not want to create a new stack on each switching point. Rather,
>
> 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. So I gave up on that approach. For X86-64 drivers we use
> similar approach, but for that there is only one calling convention and we
> don't need to switch stacks, but reshuffle arguments on stack / in
> registers.
>
> 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).
>
> Giri
You can't without copying info from one stack to another. There are
other problems, also, the only place you can get data for a stack in the
kernel dynamically is from kmalloc(GFP_ATOMIC). Other kmalloc() data
are paged which may (will) cause a double-fault if you use it for
a stack. You are not going to get much more than a page of GFP_ATOMIC
data so you can't really make a larger stack than the existing
process/kernel stack.
I have tried to just allocate data when a module is installed (in the
.bss or .data segments as static data). Unfortunately, some kernel
code traps this as a "triple fault" if I try to use it for a stack,
even though the kernel segments for ES, SS, DS, all point to the
same area(s).
I think the purpose of compressing the stack was to get rid of
NDIS, but that's only a theory. Currently, they did a good job
of it!
Cheers,
Dick Johnson
Penguin : Linux version 2.6.13 on an i686 machine (5589.54 BogoMips).
Warning : 98.36% of all statistics are fiction.
.
I apologize for the following. I tried to kill it with the above dot :
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
-
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]
| |
 |