How to start contributing to namespaces in the kernel.

[Vincent Batts]

Thanks for this public post.

vb
On Dec 29, 2014 4:17 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
> _______________________________________________
> Containers mailing list
> Containers at lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/containers
>