[CRIU] [PATCH 2/3] protobuf: Add ns.proto

[Pavel Emelyanov]

On 05/15/2013 01:08 AM, Cyrill Gorcunov wrote:
> On Wed, May 15, 2013 at 12:51:36AM +0400, Pavel Emelyanov wrote:
>> On 05/15/2013 12:47 AM, Cyrill Gorcunov wrote:
>>> On Wed, May 15, 2013 at 12:39:54AM +0400, Pavel Emelyanov wrote:
>>>> On 05/13/2013 01:29 PM, Cyrill Gorcunov wrote:
>>>>>
>>>>> We will need this enum for both -- plain namespaces
>>>>> handling and procfs ns entries.
>>>>>
>>>>> Signed-off-by: Cyrill Gorcunov <gorcunov at openvz.org>
>>>>> ---
>>>>>  protobuf/Makefile | 1 +
>>>>>  protobuf/ns.proto | 8 ++++++++
>>>>>  2 files changed, 9 insertions(+)
>>>>>  create mode 100644 protobuf/ns.proto
>>>>
>>>> As I told -- I don't see much sense in having another set
>>>> of integers describing namespaces. CLONE_ flags are enough.
>>>
>>> These integers are sequently assigned, ie we can use them as
>>> indices and we do.
>>
>> Where?
> 
> +static int open_ns_fd(struct file_desc *d)
> +{
> +	struct ns_file_info *nfi = container_of(d, struct ns_file_info, d);
> +	struct pstree_item *item, *t;
> +	struct ns_desc *nd = NULL;
> +	char path[64];
> +	int fd;
> +
> +	/*
> +	 * Find out who can open us.
> +	 *
> +	 * FIXME I need a hash or RBtree here.
> +	 */
> +	for_each_pstree_item(t) {
> +		TaskKobjIdsEntry *ids = t->ids;
> +
> +		if (ids->has_pid_ns_id && ids->pid_ns_id == nfi->nfe->ns_id) {
> +			item = t;
> +			nd = &ns_desc_array[NS_TYPES__PID];
> 
> Such &ns_desc_array[NS_TYPES__PID] better to do with some sane index name
> rather than CLONE_, no?

Why CLONE_? In _this_ case it would look like

   nd = &pid_ns_desc;

which is nicer to read that what it is now.

> .
>