`new' syscalls for m68k

`new' syscalls for m68k

[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_thread_area() are
    missing. Do we have to implement them, or should we use some other
    method for Thread Local Storage?
  - What about sys_vserver()?
  - What about sys_kexec_load()?
  - Any others we can/should drop?

I'm CCing uclinux-dev since I'd like to bring the syscalls for m68knommu in
sync with m68k afterwards.

NOTE: This patch is _not_ to be applied yet!

Thanks for your comments!

--- linux-2.6.9-rc1/arch/m68k/kernel/entry.S	2004-05-24 11:13:22.000000000 +0200
+++ linux-m68k-2.6.9-rc1/arch/m68k/kernel/entry.S	2004-09-10 21:07:03.000000000 +0200
@@ -663,3 +663,51 @@ sys_call_table:
 	.long sys_lremovexattr
 	.long sys_fremovexattr
 	.long sys_futex		/* 235 */
+	.long sys_sendfile64
+	.long sys_mincore
+	.long sys_madvise
+	.long sys_fcntl64
+	.long sys_readahead	/* 240 */
+	.long sys_sched_setaffinity
+	.long sys_sched_getaffinity
+	.long sys_ni_syscall	/* sys_set_thread_area */
+	.long sys_ni_syscall	/* sys_get_thread_area */
+	.long sys_io_setup	/* 245 */
+	.long sys_io_destroy
+	.long sys_io_getevents
+	.long sys_io_submit
+	.long sys_io_cancel
+	.long sys_fadvise64	/* 250 */
+	.long sys_exit_group
+	.long sys_lookup_dcookie
+	.long sys_epoll_create
+	.long sys_epoll_ctl
+	.long sys_epoll_wait	/* 255 */
+	.long sys_remap_file_pages
+	.long sys_set_tid_address
+	.long sys_timer_create
+	.long sys_timer_settime
+	.long sys_timer_gettime	/* 260 */
+	.long sys_timer_getoverrun
+	.long sys_timer_delete
+	.long sys_clock_settime
+	.long sys_clock_gettime
+	.long sys_clock_getres	/* 265 */
+	.long sys_clock_nanosleep
+	.long sys_statfs64
+	.long sys_fstatfs64
+	.long sys_tgkill
+	.long sys_utimes	/* 270 */
+	.long sys_fadvise64_64
+	.long sys_ni_syscall	/* sys_vserver */
+	.long sys_mbind
+	.long sys_get_mempolicy
+	.long sys_set_mempolicy	/* 275 */
+	.long sys_mq_open
+	.long sys_mq_unlink
+	.long sys_mq_timedsend
+	.long sys_mq_timedreceive
+	.long sys_mq_notify	/* 280 */
+	.long sys_mq_getsetattr
+	.long sys_ni_syscall	/* reserved for kexec */
+
--- linux-2.6.9-rc1/include/asm-m68k/unistd.h	2004-06-16 12:50:43.000000000 +0200
+++ linux-m68k-2.6.9-rc1/include/asm-m68k/unistd.h	2004-09-10 21:05:06.000000000 +0200
@@ -238,8 +238,55 @@
 #define __NR_lremovexattr	233
 #define __NR_fremovexattr	234
 #define __NR_futex		235
+#define __NR_sendfile64		236
+#define __NR_mincore		237
+#define __NR_madvise		238
+#define __NR_fcntl64		239
+#define __NR_readahead		240
+#define __NR_sched_setaffinity	241 // Do we need this?
+#define __NR_sched_getaffinity	242 // Do we need this?
+#define __NR_set_thread_area	243 // We don't have sys_set_thread_area yet
+#define __NR_get_thread_area	244 // We don't have sys_get_thread_area yet
+#define __NR_io_setup		245
+#define __NR_io_destroy		246
+#define __NR_io_getevents	247
+#define __NR_io_submit		248
+#define __NR_io_cancel		249
+#define __NR_fadvise64		250
+#define __NR_exit_group		251
+#define __NR_lookup_dcookie	252
+#define __NR_epoll_create	253
+#define __NR_epoll_ctl		254
+#define __NR_epoll_wait		255
+#define __NR_remap_file_pages	256
+#define __NR_set_tid_address	257
+#define __NR_timer_create	258
+#define __NR_timer_settime	(__NR_timer_create+1)
+#define __NR_timer_gettime	(__NR_timer_create+2)
+#define __NR_timer_getoverrun	(__NR_timer_create+3)
+#define __NR_timer_delete	(__NR_timer_create+4)
+#define __NR_clock_settime	(__NR_timer_create+5)
+#define __NR_clock_gettime	(__NR_timer_create+6)
+#define __NR_clock_getres	(__NR_timer_create+7)
+#define __NR_clock_nanosleep	(__NR_timer_create+8)
+#define __NR_statfs64		267
+#define __NR_fstatfs64		268
+#define __NR_tgkill		269
+#define __NR_utimes		270
+#define __NR_fadvise64_64	271
+#define __NR_vserver		272
+#define __NR_mbind		273
+#define __NR_get_mempolicy	274
+#define __NR_set_mempolicy	275
+#define __NR_mq_open		276
+#define __NR_mq_unlink		(__NR_mq_open+1)
+#define __NR_mq_timedsend	(__NR_mq_open+2)
+#define __NR_mq_timedreceive	(__NR_mq_open+3)
+#define __NR_mq_notify		(__NR_mq_open+4)
+#define __NR_mq_getsetattr	(__NR_mq_open+5)
+#define __NR_sys_kexec_load	282 // Do we need this?

-#define NR_syscalls		236
+#define NR_syscalls		283

 /* user-visible error numbers are in the range -1 - -124: see
    <asm-m68k/errno.h> */

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: `new' syscalls for m68k

[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 Storage?

Up to your implementation

>   - What about sys_vserver()?

Vserver project - probably dead for 2.6 since the SELinux and other
security modules can implement this same things (and a 2.6 vserver one
assumes would do likewise)

>   - What about sys_kexec_load()?

Depends if you support kexec

Re: `new' syscalls for m68k

[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 it." - Brian W. Kernighan

Re: `new' syscalls for m68k

[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 implement them, or should we use some other
> >     method for Thread Local Storage?
> 
> Up to your implementation
> 
> >   - What about sys_vserver()?

I would be happy to add a syscall reservation 
to the list of already reserved syscalls for
i386, x86_64, s390, sparc/64, sh3/4, ppc/64
and mips * ...

> Vserver project - probably dead for 2.6 since the SELinux and other
> security modules can implement this same things (and a 2.6 vserver one
> assumes would do likewise)

sorry, SELinux and friends can and do not even
remotely implement the same functionality, and
linux-vserver for 2.6 is working fine ...

best,
Herbert
 
> >   - What about sys_kexec_load()?
> 
> Depends if you support kexec
> 
> 
> -
> 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/

Re: `new' syscalls for m68k

[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
> i386, x86_64, s390, sparc/64, sh3/4, ppc/64
> and mips * ...

Also for m68k?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: `new' syscalls for m68k

[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 to add a syscall reservation
> > to the list of already reserved syscalls for
> > i386, x86_64, s390, sparc/64, sh3/4, ppc/64
> > and mips * ...
> 
> Also for m68k?

of course, linux-vserver is except for 2-3 tiny 
arch specific modifications which might go away
sooner or later (ptrace and uname) completely
arch agnostic, so there should be no problem
using it on m68k ...

TIA,
Herbert

> Gr{oetje,eeting}s,
> 
> 						Geert
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> 							    -- Linus Torvalds

Re: `new' syscalls for m68k

[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?
>   - 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 Storage?
>   - What about sys_vserver()?
>   - What about sys_kexec_load()?
>   - Any others we can/should drop?

My conclusion (so far). I will:
  - drop sys_sched_[gs]etaffinity() (no SMP on m68k), and sys_kexec_load()
  - reserve an entry for sys_vserver()
  - add waitid() (2.6.9-rc2)
  - rename p{read,write}64() to p{read,write} (cfr. m68knommu in 2.6.8.1-uc0)

Which leaves us with [sg]et_thread_area(): what do the glibc hackers have in
mind for TLS on m68k?

Thanks!

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: `new' syscalls for m68k

[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 we need all of them:
> >   - Are sys_sched_[gs]etaffinity() needed for non-SMP?
> >   - 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 Storage?
> >   - What about sys_vserver()?
> >   - What about sys_kexec_load()?
> >   - Any others we can/should drop?
> 
> My conclusion (so far). I will:
>   - drop sys_sched_[gs]etaffinity() (no SMP on m68k), and sys_kexec_load()
>   - reserve an entry for sys_vserver()

thanks,
Herbert

>   - add waitid() (2.6.9-rc2)
>   - rename p{read,write}64() to p{read,write} (cfr. m68knommu in 2.6.8.1-uc0)
> 
> Which leaves us with [sg]et_thread_area(): what do the glibc hackers have in
> mind for TLS on m68k?
> 
> Thanks!
> 
> Gr{oetje,eeting}s,
> 
> 						Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> 							    -- Linus Torvalds
> -
> 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/