Re: `new' syscalls for m68k

[Herbert Poetzl <herbert@13thfloor.at>]

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/