* Davide Libenzi wrote:
> > No, it absolutely is a matter of speed. The reason to have those
> > two implemented that way is so that they can be implemented as
> > vsyscalls completely in userspace. This means that on most modern
> > platforms you can implement the "make a threadlet when I
* Davide Libenzi davidel@xmailserver.org wrote:
No, it absolutely is a matter of speed. The reason to have those
two implemented that way is so that they can be implemented as
vsyscalls completely in userspace. This means that on most modern
platforms you can implement the make a
On Sat, 24 Feb 2007, Kyle Moffett wrote:
> On Feb 24, 2007, at 16:10:33, Davide Libenzi wrote:
> > On Sat, 24 Feb 2007, Ingo Molnar wrote:
> > > the on/off calls are shaped in a way that makes them ultimately
> > > vsyscall-able - the kernel only needs to know about the fact that we are
> > > in
On Feb 24, 2007, at 16:10:33, Davide Libenzi wrote:
On Sat, 24 Feb 2007, Ingo Molnar wrote:
the on/off calls are shaped in a way that makes them ultimately
vsyscall-able - the kernel only needs to know about the fact that
we are in a threadlet (so that the scheduler can do its special
On Sat, 24 Feb 2007, Ingo Molnar wrote:
> * Davide Libenzi wrote:
>
> > > +asmlinkage long
> > > +sys_threadlet_on(unsigned long restore_stack,
> > > + unsigned long restore_eip,
> > > + struct async_head_user __user *ahu)
>
> > > +asmlinkage long sys_threadlet_off(void)
>
>
On Sat, 24 Feb 2007, Ingo Molnar wrote:
* Davide Libenzi davidel@xmailserver.org wrote:
+asmlinkage long
+sys_threadlet_on(unsigned long restore_stack,
+ unsigned long restore_eip,
+ struct async_head_user __user *ahu)
+asmlinkage long sys_threadlet_off(void)
On Feb 24, 2007, at 16:10:33, Davide Libenzi wrote:
On Sat, 24 Feb 2007, Ingo Molnar wrote:
the on/off calls are shaped in a way that makes them ultimately
vsyscall-able - the kernel only needs to know about the fact that
we are in a threadlet (so that the scheduler can do its special
On Sat, 24 Feb 2007, Kyle Moffett wrote:
On Feb 24, 2007, at 16:10:33, Davide Libenzi wrote:
On Sat, 24 Feb 2007, Ingo Molnar wrote:
the on/off calls are shaped in a way that makes them ultimately
vsyscall-able - the kernel only needs to know about the fact that we are
in a threadlet
* Davide Libenzi wrote:
> > +asmlinkage long
> > +sys_threadlet_on(unsigned long restore_stack,
> > +unsigned long restore_eip,
> > +struct async_head_user __user *ahu)
> > +asmlinkage long sys_threadlet_off(void)
> If we have a new syscall that does the exec, we can
On Wed, 21 Feb 2007, Ingo Molnar wrote:
> +asmlinkage long
> +sys_threadlet_on(unsigned long restore_stack,
> + unsigned long restore_eip,
> + struct async_head_user __user *ahu)
> +{
> + struct task_struct *t = current;
> + struct async_head *ah = t->ah;
> +
On Wed, 21 Feb 2007, Ingo Molnar wrote:
+asmlinkage long
+sys_threadlet_on(unsigned long restore_stack,
+ unsigned long restore_eip,
+ struct async_head_user __user *ahu)
+{
+ struct task_struct *t = current;
+ struct async_head *ah = t-ah;
+ struct
* Davide Libenzi davidel@xmailserver.org wrote:
+asmlinkage long
+sys_threadlet_on(unsigned long restore_stack,
+unsigned long restore_eip,
+struct async_head_user __user *ahu)
+asmlinkage long sys_threadlet_off(void)
If we have a new syscall that does the
From: Ingo Molnar <[EMAIL PROTECTED]>
the core syslet / async system calls infrastructure code.
Is built only if CONFIG_ASYNC_SUPPORT is enabled.
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
---
kernel/Makefile |1
kernel/async.c |
From: Ingo Molnar [EMAIL PROTECTED]
the core syslet / async system calls infrastructure code.
Is built only if CONFIG_ASYNC_SUPPORT is enabled.
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
Signed-off-by: Arjan van de Ven [EMAIL PROTECTED]
---
kernel/Makefile |1
kernel/async.c | 958
14 matches
Mail list logo