Re: RFC: i386: kill !4KSTACKS

["linux-os \(Dick Johnson\)" <linux-os@analogic.com>]

On Tue, 6 Sep 2005, Jan Kiszka wrote:

> 2005/9/6, Giridhar Pemmasani <giri@lmc.cs.sunysb.edu>:
>> 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).
>>
>
> The more I think about this the more it becomes clear that this path
> will be too winding, especially when compared to the effort needed to
> patch 8K (or more) back into the kernel as an intermediate workaround.
>
> Moving the Windows code out of the kernel to userspace should be more
> helpful on the long term. It would take a small stub, something like
> tun/tap devices with wireless extensions, plus something to forward
> PCI interrupts, and you could start hacking the wrapper in a save
> harbour. If libusb is already prepared for such a task is not yet
> clear to me (at least it is lacking USB 2.0 according to the docs).
> But time will likely solve this as well.
>
> Jan
> -


The attached device-driver allocates a 0x4000 length
stack in an ioctl() procedure, uses that stack, then
returns to the old stack before returning from the
ioctl(). Since the data-space for the stack is allocated
only once (when the module is installed), the runtime
overhead is not very great. The driver runs on 2.6.13.

This just shows that it can be done! This doesn't mean
that one should actually do this!

Script started on Tue 06 Sep 2005 04:09:32 PM EDT
[root@chaos driver]# make install
Analogic StkDev : Initialization complete
[root@chaos driver]# ./tester
[root@chaos driver]# ./tester
[root@chaos driver]# ./tester
[root@chaos driver]# make remove
StkDev 6020 0 - Live 0xf0a34000
Analogic StkDev : Initialization complete
Doing something scary on the new stack!!
Actually survived!
Doing something scary on the new stack!!
Actually survived!
Doing something scary on the new stack!!
Actually survived!
Analogic StkDev : Module removed
[root@chaos driver]# exit
Script done on Tue 06 Sep 2005 04:09:55 PM EDT


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 DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Attachment: stack.tar.gz
Description: stack.tar.gz