Keith Owens <[EMAIL PROTECTED]> writes:
> I have just resigned and will be taking a long break away from
> computers. Feel free to play with the idea, otherwise I will look at
> it again sometime in October.
Well have a good rest. I have my own projects to play and so I suspect
you will get bac
Eric W. Biederman (on Fri, 03 Aug 2007 06:36:23 -0600) wrote:
>
>Well we currently keep a struct thread_info on the stack
>which while not as bad as task_struct has it's own uses
>and implications which may limit what you are trying
>to do.
Not an issue. We already copy struct thread_info when sw
On Fri, Aug 03, 2007 at 02:05:53PM +1000, Keith Owens wrote:
>...
> Long answer:
>
> * Define a config option to control whether or not extra kernel stacks
> are to be used. Set this config option by default on i386 and
> x86_64, unless EMBEDDED is set, in which case it becomes a user
> sel
Well we currently keep a struct thread_info on the stack
which while not as bad as task_struct has it's own uses
and implications which may limit what you are trying
to do.
That said a function like:
int call_on_new_stack(int (*continuation)(void *), void *closure)
{
struct task_struct *
First a bit of background for people who are not familiar with kernel
stack constructs.
* Every process has a dedicated kernel stack. In this context,
'process' includes user space processes and threads, plus those
processes that only exist inside the kernel (e.g. kswapd, xfslogd).
* When a
5 matches
Mail list logo
