headers
Serge E. Hallyn | 3 Aug 2009 20:22
Picon
Favicon

Re: [RFC v17][PATCH 14/60] pids 4/7: Add target_pids parameter to alloc_pid()

Quoting Oren Laadan (orenl@...):
> From: Sukadev Bhattiprolu <sukadev@...>
> 
> This parameter is currently NULL, but will be used in a follow-on patch.

Note that patches 1-4 of the clone_with_pid() patchset should
also be useful if we decide to re-create process trees in-kernel
and not export clone_with_pid().  (Though maybe not immediately
applicable to Alexey's current kthread_run()-based approach).

-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Serge E. Hallyn | 3 Aug 2009 20:26
Picon
Favicon

Re: [RFC v17][PATCH 16/60] pids 6/7: Define do_fork_with_pids()

Quoting Oren Laadan (orenl <at> librato.com):
> From: Sukadev Bhattiprolu <sukadev <at> linux.vnet.ibm.com>
...
> +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?

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.

-serge

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo <at> kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont <at> kvack.org"> email <at> kvack.org </a>
Permalink | Reply | 0 comments |
headers
Oren Laadan | 4 Aug 2009 10:37

Re: [RFC v17][PATCH 16/60] pids 6/7: Define do_fork_with_pids()


Serge E. Hallyn wrote:
> Quoting Oren Laadan (orenl <at> librato.com):
>> From: Sukadev Bhattiprolu <sukadev <at> linux.vnet.ibm.com>
> ...
>> +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'
(Continue reading)

Permalink | Reply | 0 comments |

Gmane