Serge E. Hallyn wrote:
> Quoting Oren Laadan (orenl@xxxxxxxxxxx):
>> From: Sukadev Bhattiprolu <sukadev@xxxxxxxxxxxxxxxxxx>
> ...
>> +struct target_pid_set {
>> + int num_pids;
>> + pid_t *target_pids;
>> +};
>
> Oren, I thought you had decided to add an extended flags field
> here, to support additional CLONE_ flags - such as CLONE_TIMENS?
Yes.
>
> I mention it now because if you're still considering that
> long-term, then IMO the syscall should not be called clone_with_pids(),
> but clone_extended(). Otherwise, to support new clone flags we'll
> either have to use unshare2 (without clone support), or add yet
> another clone variant, OR use clone_with_pids() which is a poor name
> for something which will likely be used in cases without specifying
> pids, but specifying flags not support through any other interface.
True.
Also, Suka - any objections to rename 'struct target_pid_set' to
simply 'struct pid_set' ?
Actually, it could probably be (re)used internally in the patch that
adds to cgroup a 'procs' file similar to 'tasks'
(https://lists.linux-foundation.org/pipermail/containers/2009-July/019679.html)
Oren.
--
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
