How to start contributing to namespaces in the kernel.

Timothy Chen tnachen at gmail.com
Mon Dec 29 21:31:17 UTC 2014


Thanks Eric for the detailed reply!

I want to gain more understanding and context around namespaces in the
kernel, and thought contributing is the best way to do so.

I wonder if there is a public backlog that lists open issues that you
mentioned or haven't get to work on yet?

Thanks!

Tim

On Mon, Dec 29, 2014 at 1:14 PM, Eric W. Biederman
<ebiederm at xmission.com> wrote:
>
> I was just asked how to start contributing to namespaces in the kernel
> and my reply is generic to anyone so I am making it public in the hopes
> it is of use to more people.
>
> Timothy Chen <tnachen at gmail.com> writes:
>
>> Hi Eric,
>>
>> My name is Timothy Chen and I work a lot on Mesos/Docker/Rocket that
>> all utilizes namespaces.
>>
>> I'm looking to contribute to Namespaces in the Kernel and besides
>> knowing where the code is I don't actually have much idea what the
>> process is like and what issues I can start looking at.
>>
>> I see you're the main person working with Namespaces so I wonder if
>> you can point me to where I can start learning how the patch process
>> work for namespaces, and what issues/bugs I can look at to start off
>> with?
>
> You will want to follow the containers mailling list:
> http://lists.linuxfoundation.org/mailman/listinfo/containers
>
> The standard reference for the kernel process is:
> https://www.kernel.org/doc/Documentation/SubmittingPatches
> (also found in the kernel git repo under Documentation).
>
> Priorities are set by enlightend self interest.  Aka you see a problem
> that you understand, and care about and you submit a patch.
>
> In most cases this involves working with the upstream maintainer of
> whatever subsystem the namespaces is for.   Aka all networking patches
> go through David Miller.  I tend to review namespace specific issues so
> I would appreciate a Cc.
>
> There are some outstanding issues and outstanding patches that I am a
> little behind on, as I was away from the kernel for quite a few months
> on a job hunt earlier this year.  Hopefully in the next couple of weeks
> I will finish getting that backlog cleared up.
>
> Developing namespace code is simultaneously simple and very difficult.
> On a good day a namespace is just an extra layer of indirection where
> you have to look up a name.  On a bad day the entire subsystem has to be
> rewritten so that extra layer of indirection can be supported in a clean
> way without hacks.  The general case always has to be solved for
> namespace patches to be interesting in upstream, and with a kernel that
> is going on 23 years old that can be a lot of cases to consider in some
> cases.
>
> From my perspective namespaces are essentially complete.  There are a
> few little things around the edges (as there always will be) that need
> work, but there are core seems pretty solid.  The things I am aware of
> right now are:
> - netlink passable ids for network namespaces
> - unprivileged mounts of filesystems (with the user namespace)
> - cgroup namespaces (aka getting cgroups and containers to play nice).
> - unprivileged cgroups (aka making chmod on a cgroup file not exploitable).
> - nested networking or making it reasonably easy to support containers
>   in a data center, and easy to support multiple containers on one
>   machine.
> - devices in containers - Usually this is just dealing with the fact
>   that there are no proper abstractions for a class of devices and
>   figuring out how to deal with that.
>
> My priorities are getting security issues cleared up (especially with
> user namespaces) and then getting a little feature work done so that
> more things can be done safely in user namespaces without privilege
> (especially filesystem mounting).
>
> The process for features is that when figuring out what to do and where
> to start we have conversations (generally publicly) and then write the
> code and implement.  Patches always make features ideas much more
> concrete and sometimes it can take a while.  As part of making progress
> I wound up needing to rewrite sysfs and sysctl and significant parts of
> proc, so the result would be clean and maintainable.  Conversations also
> need to be had with not just container folks but also people who
> maintain the affected subsystems.  So sometimes despite the result being
> comparatively simple easy to follow code, the road to get there can be
> long.
>
> Good luck and I hope you can find an itch in the kernel namespaces code
> you can succesfully scratch.
>
> Eric


More information about the Containers mailing list