The Carrier-Grade Linux shopping list

[Posted May 14, 2003 by corbet]

The OSDL Carrier-Grade Linux project is slowly working toward making Linux suitable for high-stakes telecommunications deployments. To that end, the group has been working on a set of requirements that Linux must meet before it is suitable for such use. The version 2 specification is, with this week's release of the CGL clustering requirements, now complete. The full documents are available on the project's web site. For the busier people among us, here is a quick summary of some of the kernel-oriented requirements.

Persistent device naming; a device should have the same name regardless of how many times it has been connected and removed.
Live software upgrades including kernel upgrades; it should be possible to put in a new kernel with less than a minute of downtime. The kexec patch should be helpful in this regard.
Multi-node volume management that works across a cluster.
Enhanced panics; it should be possible to configure what happens when the system panics, chosing between halting, rebooting, power-cycling components, etc.
Fault injection, allowing the simulation of hardware and software failures.
Page flushing, similar to that provided by the fsync() system call, but under the control of the system administrator rather than the specific application.
POSIX timers, presumably like those currently found in 2.5.
User-space semaphores and spinlocks; the 2.5 FUTEX capability should take care of this one.
Low-level asynchronous events in a scalable manner - like the 2.5 epoll() capability.
SVR4 streams, required by some applications. "Keeping it separate from the base kernel ... also would be the prudent thing to do, as providing streams in the kernel got an unfavorable reception in the past in the LKML."
Linux security module support as found in 2.5.
IPSec for IPv4, also as found in 2.5.
DRM stuff, such as checking binaries for a signature before executing them.
Atomic checkpoint support which, among other things, allow services to be quickly moved across a cluster if a node fails.
Failing node isolation so that a confused cluster node cannot corrupt resources.
Cluster messaging which offers "better quality of service than TCP/IP." Latency is of particular concern.
Storage replication over the network. Multipath storage access is also required.

All together, it is a lengthy list which will not be fully supported by Linux for quite some time yet. Knowing where you want to go is always an important first step, however.