On Tue, Mar 31, 2015 at 10:08:07PM +0200, Jonathan Corbet wrote:
> So I finally got around to having a look at this, and one thing caught my
> eye:
>
> > read(2) (and similar)
> > When the new process exits, reading from the
> > file
> > descriptor produces a single clonefd_info structure:
> >
> > struct clonefd_info {
> > uint32_t code; /* Signal code */
> > uint32_t status; /* Exit status or signal */
> > uint64_t utime; /* User CPU time */
> > uint64_t stime; /* System CPU time */
> > };
>
> This would appear to assume that a clonefd_info structure is the only
> thing that will ever be read from this descriptor. It seems to me that
> there is the potential for, someday, wanting to be able to read and write
> other things as well. Should this structure be marked with type and
> length fields so that other structures could be added in the future?
I don't think it makes sense for a caller to get an arbitrary structure
on read(), and have to figure out what they got and ignore something
they don't understand. Instead, I think it makes more sense for the
caller to say "Hey, here's a flag saying I understand the new thing, go
ahead and give me the new thing". So, for instance, if you want to
receive SIGSTOP/SIGCONT messages for child processes through this
descriptor, we could add a flag for that.
- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
