[lkml]   [2005]   [Sep]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: RFC: i386: kill !4KSTACKS
> > 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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-09-07 21:51    [W:0.088 / U:0.176 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site