Re: [RESEND][RFC PATCH v2] waitfd

[Ingo Molnar]

* Davide Libenzi <davidel@xxxxxxxxxxxxxxx> wrote:

> On Wed, 7 Jan 2009, Ingo Molnar wrote:
> 
> > 
> > * Roland McGrath <roland@xxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/