Josef Bacik proposes 'cells' to make containers first-class kernel objects

The Linux kernel has never recognized containers as a unified entity, instead offering namespaces, control groups, seccomp, and other primitives that user-space tools must manually combine. Josef Bacik, known for his work on Btrfs, is now proposing 'cells' as a new kernel abstraction that would bundle these disparate mechanisms into a single first-class object. This represents the latest in a long series of attempts to formalize container support at the kernel level, all of which have previously stalled due to complexity and differing stakeholder requirements.

The 'cells' proposal aims to reduce the fragmentation and inconsistency that currently plagues container runtimes, where each implementation assembles kernel features differently. If successful, this would give the kernel direct awareness of container boundaries, potentially enabling more coherent resource accounting, security policy enforcement, and debugging capabilities. The design is still in early stages and faces the same political and technical hurdles that sank prior efforts.

What 'cells' would change in kernel container architecture

• Unified abstraction: Cells would create a single kernel object representing a container, replacing the current model where namespaces, cgroups, and security mechanisms exist as independent components with no inherent relationship.
• Historical context: Multiple previous attempts to establish kernel-level container objects have been proposed and rejected over the years, indicating significant architectural and community barriers to this class of change.
• Component bundling: The proposal would wrap existing primitives — including PID, mount, network, and IPC namespaces, plus cgroup hierarchies and seccomp filters — into one coherent structure rather than requiring user-space orchestration.
• Developer background: Bacik brings extensive kernel experience from Btrfs development, though filesystem expertise differs from the core scheduling, memory management, and security domains most relevant to container implementation.

Why it matters

A kernel-native container object would reduce divergence between container runtimes like runc, crun, and systemd-nspawn, potentially simplifying security auditing and system administration across Linux distributions. For cloud-native infrastructure and platform engineering teams, unified kernel visibility into container boundaries could improve observability tooling and enable more precise resource attribution. However, the proposal's success depends on navigating the same governance challenges that defeated earlier attempts, and container orchestration layers like Kubernetes would not see immediate changes since they operate above the runtime level.