why the pid namespace is not compiled in the kernel ?

[Tim Gardner]

Daniel Lezcano wrote:
> Tim Gardner wrote:
>> Daniel Lezcano wrote:
>>  
>>> Tim Gardner wrote:
>>>    
>>>> Daniel Lezcano wrote:
>>>>  
>>>>      
>>>>> Tim Gardner wrote:
>>>>>           
>>>>>> Daniel Lezcano wrote:
>>>>>>  
>>>>>>               
>>>>>>> Daniel Lezcano wrote:
>>>>>>>                      
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I hope it is the right mailing list to ask  :)
>>>>>>>>
>>>>>>>> I tried the latest kernel version from "intrepid" and it looks like
>>>>>>>> the namespaces are compiled in except the pid namespace (according
>>>>>>>> the config file stored in /boot).
>>>>>>>> Is there any particular reason ?
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>  -- Daniel
>>>>>>>>
>>>>>>>> ps: I recently subscribed to this mailing list, sorry if this
>>>>>>>> question was already asked ...
>>>>>>>>                                 
>>>>>>> did I ask to the right mailing list ?
>>>>>>>
>>>>>>>                         
>>>>>> Though there are a few features included in the config that depend on
>>>>>> EXPERIMENTAL, CONFIG_PID_NS is not deemed sufficiently interesting to
>>>>>> mess with.
>>>>>>                   
>>>>> Ah, I see, like the network namespace, it is experimental, that makes
>>>>> sense.
>>>>> We will have to wait a litlle before having a full featured
>>>>> container in
>>>>> Ubuntu :)
>>>>>
>>>>> Thanks.
>>>>>  -- Daniel
>>>>>
>>>>>             
>>>> I'm not totally opposed, but you'll need to convince me with use cases
>>>> and some stability analysis.
>>>>         
>>> The namespaces with the control group provides the ability to create a
>>> virtual private server.
>>> You can launch an application like sshd or apache with its own private
>>> resources, that allows to make several instances of the same server on
>>> the same host without conflicts. You can launch several operating
>>> systems (eg. a debian) on the same host.
>>> This is different from the virtual machine because the kernel is shared
>>> and it is up to it to handle the system resources per group of
>>> processes.
>>> The advantage of this approach is the scalability and the very low
>>> overhead of the virtualization.
>>>
>>> There are two projects implementing the container feature, the libvirt
>>> and the liblxc.
>>>
>>> The pid namespace is enabled since fedora 9 and opensuse 11, and I
>>> didn't fall into any problem while using the liblxc, I guess we can
>>> consider it stable.
>>> The network namespace is mutually exclusive with sysfs until 2.6.29,  I
>>> spotted 2 bugs in the netwok namespace and I am fixing them right now,
>>> one is leading to a kernel panic (fixed) and the last one just fails
>>> gracefully, sometimes, to create a network namespace when trying to
>>> instantiate a new network namespace in a infinite loop.
>>>
>>> AFAICS, nobody complained about the namespaces being enabled in these
>>> different distros.
>>>
>>> The namespaces tests are included in the ltp test suite, so IMHO, it is
>>> reasonable to say they are stable.
>>> In any case, "experimental" is a scary word and I understand why the
>>> feature would not be enabled for a stable kernel version :)
>>> If the features are missing I can live with a custom kernel until
>>> everything is enabled.
>>>
>>> FYI, I added the lxc.7 man page to this email, I hope that can give some
>>> clues of what we can do with the namespaces and the cgroup :)
>>>
>>> Thanks.
>>>  -- Daniel
>>>     
> Hi,
> 
> The return ... :)
> 
> I was wondering if the network namespace will be enabled for the 2.6.29
> kernel version too ?
> The network namespace does not add any overhead neither extra memory
> consumption when it is enabled in the kernel.
> 
> Thanks
>   -- Daniel
> 

No Ubuntu releases use the 2.6.29 kernel, nor would this likely qualify
as an SRU for already released kernels.

-- 
Tim Gardner tim.gardner at canonical.com