lkml.org 
[lkml]   [2011]   [May]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] m68k: Merge mmu and non-mmu versions of sys_call_table
On Sat, 7 May 2011 10:34:25 +0200, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Thu, May 5, 2011 at 22:39, Mikael Pettersson <mikpe@it.uu.se> wrote:
> > Geert Uytterhoeven writes:
> > =C2=A0> On Thu, 5 May 2011, Arnd Bergmann wrote:
> > =C2=A0> > Did you check the macros in unistd to see if they match the
> > =C2=A0> > actual table? I guess it would be a good time to comment out
> > =C2=A0> > the ones that are not implemented in either of the two ABIs.
> > =C2=A0>
> > =C2=A0> Like this?
> > =C2=A0>
> > =C2=A0> warning: #warning syscall pselect6 not implemented
> > =C2=A0> warning: #warning syscall ppoll not implemented
> > =C2=A0> warning: #warning syscall recvmmsg not implemented
> > =C2=A0>
> > =C2=A0> Do we need pselect6 and ppoll? I have vague memories not requirin=
> g it.
> >
> > They close user-space race conditions, so you want them.
>
> So do you recommend to backport the wiring up of pselect6/ppoll to -stable?
> We always had their _NR_* defines, so I guess glibc was always compiled
> with pselect6/ppoll support, and will use it if it's present.

Any kernel with working TIF_RESTORE_SIGMASK should ideally also
wire up pselect6/ppoll. But their omission is not a regression
so backporting to 2.6.38 is probably sufficient.

/Mikael


\
 
 \ /
  Last update: 2011-05-07 15:19    [W:0.081 / U:1.356 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site