lkml.org 
[lkml]   [2009]   [Jan]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RESEND][RFC PATCH v2] waitfd

* Davide Libenzi <davidel@xmailserver.org> wrote:

> On Wed, 7 Jan 2009, Ingo Molnar wrote:
>
> >
> > * Roland McGrath <roland@redhat.com> wrote:
> >
> > > New syscall should have gone to linux-api, I think.
> > >
> > > Do we really need another one for this? How about using signalfd plus
> > > setting the child's exit_signal to a queuing (SIGRTMIN+n) signal instead
> > > of SIGCHLD? It's slightly more magical for the userland process to know
> > > to do that (fork -> clone SIGRTMIN). But compared to adding a syscall
> > > we don't really have to add, maybe better.
> >
> > hm, i think it's cleaner conceptually than trying to wrap this into
> > signalfd. Since we already have:
> >
> > #define __NR_signalfd 321
> > #define __NR_timerfd_create 322
> > #define __NR_timerfd_settime 325
> > #define __NR_timerfd_gettime 326
> > #define __NR_signalfd4 327
> >
> > is one more really such an issue?
>
> And what did eventfd do to you? :)

:)

> I partially agree with Roland (and I stated this during Casey's first
> post), this can be achieved in a not too troublesome way already. A new
> dedicated interface is easier for the challenged userspace coder, but I
> dunno if it's worth the new code (although it does have little
> footprint). Both ways are fine from my POV.

i think we should be defensive and generous and do a clean separate
syscall for this - we have a pretty bad track record in syscall interface
cleanliness, today's borderline hack is tomorrow's limitation causing
headaches. We never know what that extra flexibility that will buy us in
the future.

Ingo


\
 
 \ /
  Last update: 2009-01-07 22:53    [W:0.073 / U:1.532 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site