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 suppose we could just use ioctl() for any other functionality in the
future, though...:)
jon
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
