• Flexible options for booting compressed and remotely hosted kernel images
• Support of compressed r/w and read-only Flash file systems (JFFS and CramFS)
• Accelerated boot and daemon start times from several minutes to seconds, speeding shutdown and eliminating costly file system operations with journaling file systems

Carrier Grade Linux supports these requirements with:

• Boot from multiple media – from local Flash, via Ethernet, or over the CompactPCI backplane
• Flexible boot image – how much local Flash and RAM is available (Linux is smaller than you imagine!)
• Root file system – without local rotating media (disk), Linux/bin, and other key directories can mount with NFS or on local RAM or local non-volatile memory
• Rapid reboot and fast boot time – reducing boot time of CPU boards/blades after hot insertion
• Reduced halt time – during a hot removal, reduce the time that the system needs to shut down, sync file systems, etc., before enabling the Blue LED
• Journaling file systems for faster reboot

Performance and scalability
Carrier Grade Linux, with its requirement for soft, real-time performance, is the ideal operating system for telecommunications systems. Some key features include a preemptible kernel with millisecond-level real time (less than 5 msecs worst-case latencies), RAID 0 (striping), application pre-loading, and a scaling analysis and report to identify bottlenecks.

Real time
Real-time performance is critical to many carrier grade applications. The ability to respond quickly and predictably to external events is a key feature of availability.

The preferred method for implementing soft real-time support in embedded Linux is with a preemptible kernel, which redefines the Symmetric Multiprocessing (SMP) spin-lock protection regions to as non-preemptible regions in the kernel. Since concurrent use protection issues for SMP and uniprocessor kernel preemption are the analogous, drivers or kernel modules that are SMP safe are also safe for use with a preemptible kernel.

This technology has the advantage that any time the flow of execution is not in a protected region in the kernel, the current context becomes immediately preemptible. In addition, work by the Linux community to reduce the number and length of spin-lock protected regions, so-called big locks, helps to reduce the length of non-preemptible regions in the kernel, and so reduce scheduling latency.

High resolution timers
System time in standard Linux is kept in terms of jiffies. A jiffy is the period of the system clock, usually 10 msecs, although it can be as small as 1 msec on some architectures and is configurable on others. For timer or alarm resolution of less than 2 jiffies, an alternative to standard Linux timer mechanisms is required, since timer accuracy is by definition ±1 jiffy. Some embedded Linux solutions provide higher-resolution timers via alternative time bases – timers with microsecond resolution. This solution also allows for an increased maximum number of timers in the system by reducing the amount of overhead timers placed on the system from native timer interrupts and jiffy calculation.

Service ability
Features in embedded Linux that support service ability include tools for resource monitoring, kernel crash dump and analysis features, and online application patching and debugging. Other kernel-level features include structured kernel messages, dynamic kernel probing, hardware error logging, and remote access to the event log. Figure 1 depicts the flow of a typical resource monitoring subsystem.

Resource monitoring
The Carrier Grade Linux specification will provide a publish-and-subscribe resource for monitoring API usage and tracking kernel gauges. Example kernel gauges include Ethernet traffic, free memory pages, processes created, number of zombies (terminated but still present processes and threads), and current kernel load. New gauges are easy to add to a system for tracking other information, and gauges may be self-discovered by user-level software by using the unique gauge-string identifier.

Monitor options include high, low, and leaky bucket monitors. Using an API, system developers can keep track of system resources to help diagnose problems and provide preemptive remedial action before the system becomes unusable.

Dynamic probes
Dynamic kernel probing allows designers to examine data structures and establish execution break points without the requirement of compiling debug code into the kernel itself. Kernel probing allows developers to observe system behavior easily and quickly from a debugger in a running system, without having to recompile modules under observation with debug capabilities beforehand, or indeed even having to decide in advance which modules may need to be probed. Dynamic kernel probing also allows system maintainers to examine a deployed system in situ without needing to bring it down.