Re: RFC: i386: kill !4KSTACKS

[Daniel Phillips <phillips@istop.com>]

> > Is there a technical reason ("hard to implement" is a practical reason)
> > why all stacks need to be the same size?
>
> Because of
>
> static inline struct thread_info *current_thread_info(void)
> {
>         struct thread_info *ti;
>         __asm__("andl %%esp,%0; ":"=r" (ti) : "" (~(THREAD_SIZE - 1)));
>         return ti;
> }
> [include/asm-i386/thread_info.h]
>
> which assumes that it can "round down" the stack pointer and then will
> find the thread_info of the current context there. Only works for
> identically sized stacks. Note that this function is heavily used in
> the kernel, either directly or indirectly. You cannot avoid it.
>
> My current assessment regarding differently sized threads for
> ndiswrapper: not feasible with vanilla kernels.

If so, it is not because of this.  It just means you have to go back to the 
idea of switching back to the original stack when the Windows driver calls 
into the ndis API.  (It must have been way too late last night when I claimed 
the second stack switch wasn't necessary.)

Other issues:

  - Use a semaphore to serialize access to a single ndis stack... any
    spinlock or interrupt state issues?  (I didn't notice any.)

  - Copy parameters across the stack switch - a little tricky, but far from
    the trickiest bit of glue in the kernel

  - Preempt - looks like it has to be disabled from switching to the ndis
    stack to switching back because of the thread_info problem

  - It is best for Linux when life is a little hard for binary-only drivers,
    but not completely impossible.  When the smoke clears, ndis wrapper will
    be slightly slower than before and we will be slightly closer to having
    some native drivers.  In the meantime, keeping the thing alive without
    impacting core is an interesting puzzle.

Regards,

Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/