Jessica Frazelle <me@xxxxxxxxxxxx> wrote: > Adding a container object seems a bit odd to me because there are so > many different ways to make containers, aka not all namespaces are > always used This is already dealt with to some extent. It can create/inherit namespaces like fork - except that you get an extra option (literally, create with no mount namespace and create that when you provide a root mount). Modifying the namespace subscriptions is on the to-do list. > as well as not all cgroups, cgroups are on the to-do list. > various LSM objects sometimes apply, I added a hook for the LSM to use. > mounts blah blah blah. You can mount into the container and you can create sockets in the container from outside the container. > The OCI spec This? https://github.com/opencontainers/runtime-spec/blob/master/README.md > was made to cover all these things so why a kernel object? Because there are some things the kernel doesn't do that it should (upcalling into the correct namespace junction for example), and some things I've been asked to add for which there's no clear place to do so. > I don't exactly see a future where the container runtimes convert to this > unless it covers all the same mods as the mods in the OCI spec, not saying > it needs to abide by the spec, just saying it should allow all the same > things. I haven't looked at the OCI spec as yet. Note that this is *not* a replacement for a container application. I'm not trying to deprecate Docker or whatever. It's something for those container applications to use. > Which really just seems, imo, like a pain for the kernel to have to > maintain. Namespaces are a pain, particularly as lots of things exist in more than one of the things. David -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
