JSON-based configuration of kernel subsystems

The kernel contains a lot of subsystems that need to be con*gured, typically by setting key/value pairs. Moreover, sometimes the user may dynamically create new kernel entities (such as tap devices, bridges, virtual machines, . . . ) each requiring its own set of parameters, both at creation time and during its lifetime. These new entities also need unique names, so that they may be referenced afterwards and maybe connected together (e.g., a tap to a bridge).

In the netmap subsystem, for example, we need a way to create memory areas containing preallocated buers, and we want to specify the number and size of such buffers, and possibly other options such as the use of huge pages, or the selection of a NUMA node. Once a memory area has been created, we want to bind selected netmap ports to it, e.g., to isolate ports passed through to virtual machines, or ports used by independent applications or users. To do this comfortably and reliably, we would like to specify all the parameters atomically at creation and bind time.

Current solutions to these kind of problems either involve ad-hoc primitives (e.g., ioctl()) and tools to call them, or try to use more general mechanisms such as the sysctl interface or a pseudo-lesystem. We think that general mechanisms are preferable, since the in-kernel code may be reused and the user does not need to learn new tools. Unfortunately, neither sysctls, nor pseudo-lesystems have a natural way to express atomicity: each sysctl entry or pseudo-*le write and read operation is independent from all others. Several concurrent scripts that need to create and manipulate similar entities may interfere with each other, unless particular care is taken.

We propose to use an (extended) JSON-based protocol for kernel subsystems conguration. Users may write a JSON specication to a special device; if the device is kept open, they may also read a JSON reply from the kernel. All actions specifyied between the initial open() and a following read() (or close()) are executed atomically by the kernel. The JSON input refers to kernel "objects", organized in a hierarchy, and their properties. E.g., <pre><code>{ "netmap": { "mem": { "1": { "buffers": 100000, "size": 2048 }}}}</code></pre> may be used to (atomically) set the number of buers and their size in the already existing netmap memory area with ID 1. Extended syntax is used to inspect, rather than set, values: <pre><code>{ "netmap": { "mem": { "1": { "free-buffers": ? }}}}</code></pre> By writing this request to the special device, and then reading from it, one would obtain something like: <pre><code>{ "netmap": { "mem": { "1": { "free-buffers": 531 }}}}</code></pre> Another extension to the syntax allows for the creation of new objects and symbolic manipulation of their automatically assigned unique identiers: <pre><code> { "netmap": {

"mem": { &X: { "buffers": 100000, "size": 2048 }}}
"port": { "em0" : { "mem": X } }

} } </code></pre> This will atomically create a new memory area with 100000 bu*ers of 2048 bytes, and bind port em0 to it.

We have implemented a tiny JSON parser and most of the above features for the conguration of the netmap subsystem. The JSON parser is about 700 lines of code (including comments) and uses a compact representation for the parsed objects. We have chosen JSON because its object syntax naturally relates to the in-kernel objects, and because of the extensive availability of userspace libraries and tools that parse and output JSON. We are nonetheless aware that JSON, while certainly more human-friendly than XML, is still a terribly annoying syntax for interactive command line usage. For this reason, our parser accepts some syntax extensions that allow, in most cases, avoid unnecessary quotes and curly braces. E.g., the first example above may also be written as <pre><code>netmap.mem.1: { buffers: 100000, size: 2048 }</code></pre>

Note, fi*nally, that the hierarchical nature of the parsing allows for incremental development: subsystems may adopt our proposal one at a time, without interference with other subsystems.