All of lore.kernel.org
 help / color / mirror / Atom feed
From: Randy Dunlap <randy.dunlap@oracle.com>
To: Casey Dahlin <cdahlin@redhat.com>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH v2] waitfd
Date: Tue, 06 Jan 2009 10:50:01 -0800	[thread overview]
Message-ID: <4963A7D9.2030604@oracle.com> (raw)
In-Reply-To: <4963A6D9.9080206@redhat.com>

Casey Dahlin wrote:
> Randy Dunlap wrote:
>> Casey Dahlin wrote:
>>  
>>> Linux now exposes signals, timers, and events via file descriptors
>>> through signalfd, timerfd, and eventfd. This means programmers can use a
>>> single select/[e]poll call to monitor all change in their program. This
>>> patch aims to expose child death via the same mechanism.
>>>
>>> waitfd provides a file descriptor out of which may be read a series of
>>> siginfo_t objects describing child death. A child process is reaped as
>>> soon as its information is read. This means child monitoring too can be
>>> performed with that same poll call.
>>>
>>> Patch is against v2.6.28
>>>
>>> --CJD
>>>
>>> diff --git a/arch/x86/include/asm/unistd_32.h
>>> b/arch/x86/include/asm/unistd_32.h
>>> index f2bba78..134d83c 100644
>>> --- a/arch/x86/include/asm/unistd_32.h
>>> +++ b/arch/x86/include/asm/unistd_32.h
>>> @@ -338,6 +338,7 @@
>>> #define __NR_dup3        330
>>> #define __NR_pipe2        331
>>> #define __NR_inotify_init1    332
>>> +#define __NR_waitfd        333
>>>
>>> #ifdef __KERNEL__
>>>
>>> diff --git a/arch/x86/include/asm/unistd_64.h
>>> b/arch/x86/include/asm/unistd_64.h
>>> index d2e415e..b28eb07 100644
>>> --- a/arch/x86/include/asm/unistd_64.h
>>> +++ b/arch/x86/include/asm/unistd_64.h
>>> @@ -653,6 +653,8 @@ __SYSCALL(__NR_dup3, sys_dup3)
>>> __SYSCALL(__NR_pipe2, sys_pipe2)
>>> #define __NR_inotify_init1            294
>>> __SYSCALL(__NR_inotify_init1, sys_inotify_init1)
>>> +#define __NR_waitfd                295
>>> +__SYSCALL(__NR_waitfd, sys_waitfd)
>>>
>>>     
>>
>> Only for x86??
>>
>>   
> 
> At the moment. I should have mentioned this earlier but I haven't made
> the syscall table entries for archs I don't test on. That will change
> once the rest of the change has settled out.


>>> diff --git a/fs/waitfd.c b/fs/waitfd.c
>>> new file mode 100644
>>> index 0000000..0155a83
>>> --- /dev/null
>>> +++ b/fs/waitfd.c
>>> @@ -0,0 +1,117 @@
>>> +/*
>>> + *  fs/waitfd.c
>>> + *
>>> + *  Copyright (C) 2008  Red Hat, Casey Dahlin <cdahlin@redhat.com>
>>> + *
>>> + *  Largely derived from fs/signalfd.c
>>> + */
>>> +
>>> +#include <linux/file.h>
>>> +#include <linux/poll.h>
>>> +#include <linux/init.h>
>>> +#include <linux/fs.h>
>>> +#include <linux/sched.h>
>>> +#include <linux/kernel.h>
>>> +#include <linux/signal.h>
>>> +#include <linux/list.h>
>>> +#include <linux/anon_inodes.h>
>>> +#include <linux/syscalls.h>
>>> +
>>> +long do_waitid(int which, pid_t upid,
>>> +           struct siginfo __user *infop, int options,
>>> +           struct rusage __user *ru);
>>> +
>>> +struct waitfd_ctx {
>>> +    int ops;
>>> +    int which;
>>> +    pid_t upid;
>>> +};
>>> +
>>>     
>>
>> Please use kernel coding style:  use tabs to indent, not
>> <lots-of-spaces>,
>> and struct members, functions, etc., are indented by one tab stop
>> minimum.
>>
>>   
> 
> Damnit. This is a mailer artifact. This is the first time thunderbird
> has eaten a patch on me. I'll look in to it.

OK.
You can see if Documentation/email-clients.txt helps you any.

>>> +}
>>> +
>>> +static const struct file_operations waitfd_fops = {
>>> +    .release    = waitfd_release,
>>> +    .poll        = waitfd_poll,
>>> +    .read        = waitfd_read,
>>> +};
>>> +
>>> +asmlinkage long sys_waitfd(int which, pid_t upid, int options, int
>>> unused)
>>> +{
>>> +    int ufd;
>>> +    struct waitfd_ctx *ctx;
>>> +
>>> +    /* Just to make sure we don't end up with a sys_waitfd4 */
>>> +    (void)unused;
>>> +
>>> +    if (options & ~(WNOHANG|WEXITED|WSTOPPED|WCONTINUED))
>>> +        return -EINVAL;
>>> +    if (!(options & (WEXITED|WSTOPPED|WCONTINUED)))
>>> +        return -EINVAL;
>>>     
>>
>> Use spaces around '|'.
>>
>>   
> 
> Those 4 lines are copied almost exactly from kernel/exit.c. Is there
> motivation to keep them consistent?

I would say no.

-- 
~Randy

  reply	other threads:[~2009-01-06 18:50 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-06 18:11 [RFC PATCH v2] waitfd Casey Dahlin
2009-01-06 18:27 ` Alan Cox
2009-01-06 18:31 ` Randy Dunlap
2009-01-06 18:45   ` Casey Dahlin
2009-01-06 18:50     ` Randy Dunlap [this message]
2009-01-06 18:48 ` Andi Kleen
2009-01-06 19:07 ` [RESEND][RFC " Casey Dahlin
2009-01-07 12:34   ` Ingo Molnar
2009-01-07 13:05     ` Casey Dahlin
2009-01-07 15:00       ` Ingo Molnar
2009-01-07 17:19     ` Oleg Nesterov
2009-01-07 17:24       ` Ingo Molnar
2009-01-07 17:52       ` Davide Libenzi
2009-01-07 20:38         ` Casey Dahlin
2009-01-10 14:47       ` Scott James Remnant
2009-01-10 21:14         ` Casey Dahlin
2009-01-10 21:20           ` Scott James Remnant
2009-01-10 22:08             ` Casey Dahlin
2009-01-10 22:31           ` Oleg Nesterov
2009-01-10 22:37             ` Casey Dahlin
2009-01-10 22:46               ` Oleg Nesterov
2009-01-07 20:53     ` Roland McGrath
2009-01-07 20:58       ` Ingo Molnar
2009-01-07 21:05         ` Davide Libenzi
2009-01-07 21:50           ` Ingo Molnar
2009-01-07 21:02       ` Ulrich Drepper
2009-01-08 14:32         ` Oleg Nesterov
2009-01-08 19:35           ` Roland McGrath
2009-01-08 20:36             ` Casey Dahlin
2009-01-08 21:39               ` Oleg Nesterov
2009-01-10 14:52                 ` Scott James Remnant
2009-01-10 16:19                   ` Oleg Nesterov
2009-01-10 17:09                     ` Scott James Remnant
2009-01-10 18:21                       ` Oleg Nesterov
2009-01-10 18:46                         ` Scott James Remnant
2009-01-10 14:50               ` Scott James Remnant
2009-01-10 21:20                 ` Casey Dahlin
2009-01-08 22:04       ` Michael Kerrisk
2009-01-10 14:09       ` Scott James Remnant
2009-01-10 14:45       ` Scott James Remnant
2009-01-10 15:57         ` Oleg Nesterov
2009-01-10 17:07           ` Scott James Remnant
2009-01-10 18:13             ` Oleg Nesterov
2009-01-10 20:13               ` Scott James Remnant
2009-01-10 22:24                 ` Oleg Nesterov
2009-01-10 23:14                   ` Davide Libenzi
2009-01-10 22:25             ` Casey Dahlin
2009-01-10 23:11             ` Davide Libenzi
2011-03-02  1:37           ` Denys Vlasenko
2011-03-02 13:55             ` Oleg Nesterov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4963A7D9.2030604@oracle.com \
    --to=randy.dunlap@oracle.com \
    --cc=cdahlin@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.