Re: [uClinux-dev] Re: `new' syscalls for m68k

2004-10-26 Thread Paul Mundt
On Sun, Oct 24, 2004 at 10:44:40PM +0200, Geert Uytterhoeven wrote: > > On Fri, 10 Sep 2004, Geert Uytterhoeven wrote: > > > I'm updating the syscall table for m68k... > > - add sys_setaltroot() (2.6.10-rc1) According to akpm setaltroot is going away, so you will probably want to drop this (the

Re: [uClinux-dev] Re: `new' syscalls for m68k

2004-10-25 Thread Paul Mundt
On Mon, Oct 25, 2004 at 06:19:10PM +0200, Geert Uytterhoeven wrote: > We would just add it at the end? No compatibility problem. Syscall numbers are > different on different architectures anyway. > Yes, that's true. Most platforms don't go out of their way to have radically out-of-order syscall ta

Re: [uClinux-dev] Re: `new' syscalls for m68k

2004-10-25 Thread Geert Uytterhoeven
On Mon, 25 Oct 2004, Paul Mundt wrote: > On Mon, Oct 25, 2004 at 05:50:41PM +0200, Geert Uytterhoeven wrote: > > > The syscall after sys_mq_getsetattr and before sys_waitid is reserved > > > for kexec, is there some reason that this isn't being filled as a > > > sys_ni_syscall for the time being in

Re: [uClinux-dev] Re: `new' syscalls for m68k

2004-10-25 Thread Paul Mundt
On Mon, Oct 25, 2004 at 05:50:41PM +0200, Geert Uytterhoeven wrote: > > The syscall after sys_mq_getsetattr and before sys_waitid is reserved > > for kexec, is there some reason that this isn't being filled as a > > sys_ni_syscall for the time being instead? > > I dropped it because there's no imp

Re: [uClinux-dev] Re: `new' syscalls for m68k

2004-10-25 Thread Geert Uytterhoeven
On Mon, 25 Oct 2004, Paul Mundt wrote: > On Sun, Oct 24, 2004 at 10:44:40PM +0200, Geert Uytterhoeven wrote: > > + .long sys_mq_notify /* 275 */ > > + .long sys_mq_getsetattr > > + .long sys_waitid > > + .long sys_setaltroot > > + .long sys_add_key > > + .long sys_request_key /* 2

Re: [uClinux-dev] Re: `new' syscalls for m68k

2004-10-25 Thread Paul Mundt
On Sun, Oct 24, 2004 at 10:44:40PM +0200, Geert Uytterhoeven wrote: > + .long sys_mq_notify /* 275 */ > + .long sys_mq_getsetattr > + .long sys_waitid > + .long sys_setaltroot > + .long sys_add_key > + .long sys_request_key /* 280 */ > + .long sys_keyctl The sysca

Re: `new' syscalls for m68k

2004-10-24 Thread Geert Uytterhoeven
On Thu, 16 Sep 2004, Geert Uytterhoeven wrote: > On Fri, 10 Sep 2004, Geert Uytterhoeven wrote: > > I'm updating the syscall table for m68k... And below is the result. Recent changes: - drop [sg]et_thread_area() - add sys_setaltroot() (2.6.10-rc1) - add key management syscalls (2.6.10-rc1)

Re: `new' syscalls for m68k

2004-09-16 Thread Herbert Poetzl
On Thu, Sep 16, 2004 at 10:23:08AM +0200, Geert Uytterhoeven wrote: > On Fri, 10 Sep 2004, Geert Uytterhoeven wrote: > > I'm updating the syscall table for m68k... > > > > Below is a patch that adds all syscalls that m68k is currently lacking > > (compared to ia32). However, I'm wondering whether w

Re: `new' syscalls for m68k

2004-09-16 Thread Geert Uytterhoeven
On Fri, 10 Sep 2004, Geert Uytterhoeven wrote: > I'm updating the syscall table for m68k... > > Below is a patch that adds all syscalls that m68k is currently lacking > (compared to ia32). However, I'm wondering whether we need all of them: > - Are sys_sched_[gs]etaffinity() needed for non-SMP? >

Re: `new' syscalls for m68k

2004-09-13 Thread Herbert Poetzl
On Mon, Sep 13, 2004 at 01:17:10PM +0200, Geert Uytterhoeven wrote: > On Sun, 12 Sep 2004, Herbert Poetzl wrote: > > On Fri, Sep 10, 2004 at 10:48:16PM +0100, Alan Cox wrote: > > > On Gwe, 2004-09-10 at 21:57, Geert Uytterhoeven wrote: > > > > - What about sys_vserver()? > > > > I would be happy

Re: `new' syscalls for m68k

2004-09-13 Thread Geert Uytterhoeven
On Sun, 12 Sep 2004, Herbert Poetzl wrote: > On Fri, Sep 10, 2004 at 10:48:16PM +0100, Alan Cox wrote: > > On Gwe, 2004-09-10 at 21:57, Geert Uytterhoeven wrote: > > > - What about sys_vserver()? > > I would be happy to add a syscall reservation > to the list of already reserved syscalls for > i3

Re: `new' syscalls for m68k

2004-09-12 Thread Herbert Poetzl
On Fri, Sep 10, 2004 at 10:48:16PM +0100, Alan Cox wrote: > On Gwe, 2004-09-10 at 21:57, Geert Uytterhoeven wrote: > > - Are sys_sched_[gs]etaffinity() needed for non-SMP? > Not really > > > - I disabled [sg]et_thread_area() since sys_[gs]et_thread_area() are > > missing. Do we have to imp

Re: `new' syscalls for m68k

2004-09-11 Thread Rik van Riel
On Fri, 10 Sep 2004, Geert Uytterhoeven wrote: > NOTE: This patch is _not_ to be applied yet! That's just baiting ;) -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug

Re: `new' syscalls for m68k

2004-09-10 Thread Alan Cox
On Gwe, 2004-09-10 at 21:57, Geert Uytterhoeven wrote: > - Are sys_sched_[gs]etaffinity() needed for non-SMP? Not really > - I disabled [sg]et_thread_area() since sys_[gs]et_thread_area() are > missing. Do we have to implement them, or should we use some other > method for Thread Local

`new' syscalls for m68k

2004-09-10 Thread Geert Uytterhoeven
I'm updating the syscall table for m68k... Below is a patch that adds all syscalls that m68k is currently lacking (compared to ia32). However, I'm wondering whether we need all of them: - Are sys_sched_[gs]etaffinity() needed for non-SMP? - I disabled [sg]et_thread_area() since sys_[gs]et_thr