Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 4 Aug 2012 23:49:42 +0200
From:      Jilles Tjoelker <jilles@stack.nl>
To:        "Jukka A. Ukkonen" <jau@oxit.fi>
Cc:        freebsd-standards@FreeBSD.org
Subject:   Re: standards/170346: Changes to support waitid() and related stuff
Message-ID:  <20120804214942.GB99630@stack.nl>
In-Reply-To: <201208040620.q746K8iP036622@freefall.freebsd.org>
References:  <201208040620.q746K8iP036622@freefall.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Aug 04, 2012 at 06:20:08AM +0000, Jukka A. Ukkonen wrote:
> From: "Jukka A. Ukkonen" <jau@oxit.fi>
> To: bug-followup@FreeBSD.org, jau@iki.fi
> Cc:  
> Subject: Re: standards/170346: Changes to support waitid() and related stuff
> Date: Sat, 04 Aug 2012 09:14:21 +0300

>  These links might shed some more light to the optimal
>  placement of the idtype_t definition.

>  http://www.unix.com/man-page/OpenSolaris/2/getacct/

>  http://www.unix.com/man-page/OpenSolaris/2/sigsend/

>  Both of these manual pages apply to Solaris-11. The same
>  features are apparently also in HP-UX, but they are not
>  SUS/POSIX - at least not yet.
>  Esp. the sigsend() style functionality as a generalized
>  kill() seems to me like a potential candidate to make it
>  also to SUS/POSIX. Such functionality would be a natural
>  companion to wait*() with generalized idtype_t and id_t.

Although sigsend() may be better than requesting a process list,
matching against it and calling kill() for each matching process because
it can ensure a snapshot is taken and signaled, I still doubt this has a
place in the kernel. OpenSolaris's sigsendset() call particularly looks
like someone needed a particular set and then made it pseudo-generic. At
some point you will have to defer the filtering to userland because it
becomes too complicated and specific, and absent any specific reason it
seems best to make that point the POSIX kill() call (with the obvious
extension of only killing processes within the same jail).

>  And in any case it seems likely that id_t and idtype_t
>  will be used together almost anywhere where one is
>  needed. Neither of them makes a whole lot sense
>  without the other. So, keeping them together in the
>  header files may be beneficial.

The id_t type may be useful by itself in applications with some
application-specific way of distinguishing the various types of IDs.
Note that POSIX.1-2008 only specifies the values P_ALL, P_PGID and P_PID
for idtype_t, while an id_t may also contain a UID or a GID.

-- 
Jilles Tjoelker



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120804214942.GB99630>