In this chapter, you will be presented with information about the last topic of the book, the Carrier Grade Linux (CGL) and Linux Standard Base (LSB) initiative and of course, a parallel with what there is integrated and supported related to those two standards into the Yocto Project. This will also be mentioned here and you will not only be able to find a little bit about these standards and their specifications, but also about the level of support that Yocto offers for them. I will also present some of the initiatives adjacent to CGL, such as Automotive Grade Linux and Carrier Grade Virtualization. They also constitute viable solutions that are available in a wide palette of applications.
The latest report published by the guys working at the Linux Foundation shows how the development of the Linux kernel is actually done nowadays, what it's like to work on it, who is sponsoring it, what changes are being made to it, and how fast things are moving. The report is available at https://www.linuxfoundation.org/publications/linux-foundation/who-writes-linux-2015.
As depicted in the report, less than 20 percent of development on the kernel is done by individual developers. Most of the development is realized by companies, such as Intel, Red Hat, Linaro, Samsung, and others. This means that over 80 percent of the developers working at Linux kernel development are paid for their job. The fact that Linaro and Samsung are some of the companies with the most number of commits, only presents a favorable perception of the ARM processors in general, and Android in particular.
Another interesting piece of information is that more than half of the Linux kernel developers are at their first commit. This means that a really small number of developers are doing the vast majority of work. This dysfunction in the development of the Linux kernel process is being tried to be reduced by the Linux Foundation by offering various programs for students to make them more involved in the development process. Whether this is a success, only time will tell, but it is my opinion that they are doing the right thing and are moving in the right direction.
All of this information has been explained with regard to the Linux kernel, but parts of it are applicable for other open source components. The thing that I want to emphasize here is that the ARM support in Linux is much more mature than in architectures such as PowerPC or MIPS. This has started to not only be obvious, but is also an indication of the approach that the Intel x86 stage has taken. Until now, this approach was simply not disturbed by anyone.
LSB appeared to lower the costs of support offered by Linux platforms by reducing the differences between various available Linux distributions. It also helps with costs for porting applications. Every time a developer writes an application, they need to make sure that the source code produced on one Linux distribution will also be able to be executed on other distributions as well. They would also like to make sure that this remains possible over the years.
From time to time, whenever a new specification document is released, a testing kit is also made available to vendors to test the kit's compliance to a particular version. The vendors could test their product compliance, which can be in the form of an application or a Linux distribution. The result of the testing kit is a certification that indicates that their product is LSB certified. For an application we, of course, have an LSB Application Testkit. There is also a similar one for a Linux distribution as well as others that are available for a variety of distributions.
For vendors who are interested in optional modules, these are not only available to help vendors prepare their future LSB compliance certification, but also to expose them to optional modules in order to get more vocal reviews and contributions from them. Also, the vendor's vote is related to the existence of these modules in future LSB specification documentations whose release is also important. The vendors could establish whether one optional module is eligible for future inclusions or not.
There are clearly defined roles in workgroups:
- Contributor: This refers to actively involved individuals. They always have list with them available for the Chairperson, but any individual may request inclusion to the Contributors list.
- Chairperson: This refers to the representative Project leader. A person is elected to this position by Contributors and approved by the Steering Committee and the Linux Foundation board. Once elected, they are able to hold this position for two years. There is no limit to the number of times someone can be elected. Removal from this position can occur in case of a lack of confidence on behalf of the Steering Committee or the Linux Foundation board. After the position is vacant, a new election is carried out. During the vacancy period, the Steering Committee will assign an acting Chairperson.
- Election Committee: This refers to a committee of Contributors that are established by the Steering Committee for Chairperson election. It is responsible for selecting candidates for the position of Chairperson within at least 30 days before the Chairperson's term expires or 10 days after the Chairperson's position is vacant. It is responsible for conducting elections, which is done through electronic ballots. There is only one vote accepted from an individual; the votes are secret and only done by eligible members. The voting period is one week, and then the results are presented to the Steering Committee, which approves the votes and declares the winner.
- Steering Committee: It consists of representative workgroup stakeholders. They may be distribution vendors, OEMs, ISVs, upstream developers, and the Chairpersons of the LSB sub workgroups that come under the LSB charter. The committee is appointed by the Chairperson and depending on their involvement in workgroup activities, they can keep the position indefinitely. One member can be removed from the Steering Committee by three entities: the Chairperson, the other Steering Committee members, or by the Linux Foundation board.
Here is an image depicting a more detailed structure of the LSB workgroup:
The LSB is a fairly complex structure, as depicted in the preceding image, so more roles can be defined in a workgroup if necessary. The main focus of the workgroup remains its mission; for this to be achievable, new workgroups need to be promoted and nurtured. They require a certain level of independence, but also be accountable for the activities done in the LSB Chairperson. This mainly involves making sure that certain deadlines are met and that the project sticks to its roadmap.
Architecture independent components contain five modules:
There is, of course, another structure used to order them. Here, I am referring to the fact that some of these are mandatory and others are in a state of trial and testing. The first category is in order to have a distribution that is compliant with LSB standards, while the second category is not a strict requirement for having a compliant distribution that could represent future candidates for the next few versions of LSB.
Before moving to the next section, I want to introduce one more thing. As depicted in the previous diagram, any activity that is executed by a developer, with regard to the components of the LSB workgroup, should be done after the LSB specifications are inspected and the appropriate version is selected. For example, in the CGL Specifications, there is an explicit requirement of at least LSB 3.0, as well as the required modules, that are indicated in the same requirement description. For developers who want more information about the required specification and its components, refer to http://refspecs.linuxfoundation.org/lsb.shtml. Make sure that you also inspect the progress made on the newly available LSB 5 specifications, which passed the beta stage and, at the moment, is in its RC1 state. More information about this is available at https://www.linuxfoundation.org/collaborate/workgroups/lsb/lsb-50-rc1.
Multiple options will be discussed in this section, and we'll start by defining the term carrier grade. This seems like the perfect start. So, what does this term mean in a telecommunications environment? It refers to a system, software, and even hardware components that are really reliable. Here, I am not referring only to the five-nines or six-nines that CGL provides because not all industries and scenarios require this kind of reliability. We are only going to refer to something that can be defined as reliable in the scope of a project. For a system, software, or hardware component to be defined as carrier grade, it should also prove itself as well tested along with all sorts of functionalities, such as high availability, fault tolerance, and so on.
It is the first and oldest option available. It appeared as a necessity for the telecommunication industry in order to define a set of specifications, which in turn defined a set of standards for Linux-based operating systems. After implementations, this would make the system carrier grade capable.
The workgroup was initially started by the Open Source Development Lab (OSDL), which after its merger with Free Standards Group formed The Linux Foundation. Now all the work moved there together with the workgroup. The latest available release for CGL is 5.0 and it includes registered Linux distributions, such as Wind River, MontaVista, and Red Flag.
The OSDL CGL workgroup has three categories of applications that CGL could fit into:
- Signalling server applications: This includes products that provide control services for calls and services, such as routing, session control, and status. These products usually handle a large number of connections, around 10000 or 100000 simultaneous ones, and also because that they have real-time requirements that require obtaining results from processes under a millisecond.
- Gateway applications: These provide the bridging of technology and administrative domains. Besides the characteristics that have been mentioned already, these handle a large number of connections in a real-time environment over a not very large number of interfaces. These are also required to not lose frames or packages in the communication process.
- Management applications: These usually provide billing operations, network management, and other traditional services. They does not have the same strong requirements for real-time operations, but instead, concentrate on fast database operations and other communication-oriented requests.
To make sure that it is able to satisfy the preceding categories, the CGL workgroup focuses on two main activities. The first one involves communicating with all the preceding categories, the identification of their requirements, and the writing specifications that should be implemented by distribution vendors. The second one involves gathering and helping projects that meet the requirements defined in the specifications. As a conclusion to what I mentioned previously, CGL tries to represent not only the telecommunication industry representatives and Linux distributions, but also end users and service providers; it also provides carrier grade options for each one of these categories.
Since the requirement for number of functionalities is big, the workgroup decided to group them into various categories as follows:
- Availability: It is relevant for single node availability and recovery.
- Clustering: It describes components that are useful in building a cluster from individual systems. The key target behind this is the high availability of the system and load balancing that could also bring some performance improvements.
- Serviceability: It covers the maintenance and servicing features of the system.
- Performance: It describes features, such as real-time requirements and others, that could help the system attain better performance.
- Standards: These are provided as references to various APIs, standards, and specifications.
- Hardware: It presents various hardware-specific support that is necessary for a carrier grade operating system. Much of it comes from hardware vendors who are themselves involved in this process and the requirements from this section has been highly diminished in the latest CGL specification release.
- Security: It represents the relevant features needed to build a secure system.
Automotive Grade Linux is also a Linux Foundation workgroup. It is newly formed and tries to offer an open source solution that has automotive applications. Its primary focus is the In-Vehicle-Infotainment sector, but it includes telematics systems and instrument clusters. It efforts are based on open source components that are already available. These are suitable for its purposes and try to also enable rapid development, which is much needed in this industry.
The goals of the workgroup are:
- A transparent, collaborative, and open environment for involved elements.
- A Linux operating system stack that is focused on automotives and uses the open source community represented by exponents, such as developers, academic components, and companies as back support.
- A collective voice for interaction in the open source community released this time in the reverse form, from the AGL to the community.
- An embedded Linux distribution used for fast prototyping.
By using projects, such as Tizen, as the reference distribution and having projects, such as Jaguar, Nissan, Land Rover, or Toyoto, this project is interesting enough to be followed closely. It has just been developed but has potential for improvements. For those of you interested in it, refer to https://www.linuxfoundation.org/collaborate/workgroups/automotive-grade-linux. The project's wiki page is an interesting resource and can be consulted at https://wiki.automotivelinux.org/.
The recent development of CGL made virtualization an interesting option for the carrier grade field because it involved a reduction in costs as well as transparency in leveraging multicore equipment that runs single-core designed applications. Virtualization options also needed to meet the same expectations as the other carrier grade systems.
Carrier Grade Virtualization has tried to become a vital component to be integrated in carrier grade platforms that are already available. This is done to preserve the attributes and performance of the system. It also tries to extend the appliance target and permits Original Equipment Manufacturer (OEM) to derive the benefits from the same support as the CGL. These benefits are in the form of well established targets.
Virtualization's application is more widespread, which can be seen ranging from the x86 architecture to ARM and DSP-based processors as well as a variety of domains. The examination of virtualization from a carrier grade point of view is the focus of this solution because, in this way, you can get a clearer perspective of the areas that require improvements. In this way, these can be identified and enhancements can also be applied as required. Unfortunately, this initiative has not been as exposed as some other ones, but is still a very good source of documentation and is available from virtualLogix at http://www.linuxpundit.com/documents/CGV_WP_Final_FN.pdf. I hope you enjoy its content.
option available. It appeared as a necessity for the telecommunication industry in order to define a set of specifications, which in turn defined a set of standards for Linux-based operating systems. After implementations, this would make the system carrier grade capable.
The workgroup was initially started by the Open Source Development Lab (OSDL), which after its merger with Free Standards Group formed The Linux Foundation. Now all the work moved there together with the workgroup. The latest available release for CGL is 5.0 and it includes registered Linux distributions, such as Wind River, MontaVista, and Red Flag.
The OSDL CGL workgroup has three categories of applications that CGL could fit into:
- Signalling server applications: This includes products that provide control services for calls and services, such as routing, session control, and status. These products usually handle a large number of connections, around 10000 or 100000 simultaneous ones, and also because that they have real-time requirements that require obtaining results from processes under a millisecond.
- Gateway applications: These provide the bridging of technology and administrative domains. Besides the characteristics that have been mentioned already, these handle a large number of connections in a real-time environment over a not very large number of interfaces. These are also required to not lose frames or packages in the communication process.
- Management applications: These usually provide billing operations, network management, and other traditional services. They does not have the same strong requirements for real-time operations, but instead, concentrate on fast database operations and other communication-oriented requests.
To make sure that it is able to satisfy the preceding categories, the CGL workgroup focuses on two main activities. The first one involves communicating with all the preceding categories, the identification of their requirements, and the writing specifications that should be implemented by distribution vendors. The second one involves gathering and helping projects that meet the requirements defined in the specifications. As a conclusion to what I mentioned previously, CGL tries to represent not only the telecommunication industry representatives and Linux distributions, but also end users and service providers; it also provides carrier grade options for each one of these categories.
Since the requirement for number of functionalities is big, the workgroup decided to group them into various categories as follows:
- Availability: It is relevant for single node availability and recovery.
- Clustering: It describes components that are useful in building a cluster from individual systems. The key target behind this is the high availability of the system and load balancing that could also bring some performance improvements.
- Serviceability: It covers the maintenance and servicing features of the system.
- Performance: It describes features, such as real-time requirements and others, that could help the system attain better performance.
- Standards: These are provided as references to various APIs, standards, and specifications.
- Hardware: It presents various hardware-specific support that is necessary for a carrier grade operating system. Much of it comes from hardware vendors who are themselves involved in this process and the requirements from this section has been highly diminished in the latest CGL specification release.
- Security: It represents the relevant features needed to build a secure system.
Automotive Grade Linux is also a Linux Foundation workgroup. It is newly formed and tries to offer an open source solution that has automotive applications. Its primary focus is the In-Vehicle-Infotainment sector, but it includes telematics systems and instrument clusters. It efforts are based on open source components that are already available. These are suitable for its purposes and try to also enable rapid development, which is much needed in this industry.
The goals of the workgroup are:
- A transparent, collaborative, and open environment for involved elements.
- A Linux operating system stack that is focused on automotives and uses the open source community represented by exponents, such as developers, academic components, and companies as back support.
- A collective voice for interaction in the open source community released this time in the reverse form, from the AGL to the community.
- An embedded Linux distribution used for fast prototyping.
By using projects, such as Tizen, as the reference distribution and having projects, such as Jaguar, Nissan, Land Rover, or Toyoto, this project is interesting enough to be followed closely. It has just been developed but has potential for improvements. For those of you interested in it, refer to https://www.linuxfoundation.org/collaborate/workgroups/automotive-grade-linux. The project's wiki page is an interesting resource and can be consulted at https://wiki.automotivelinux.org/.
The recent development of CGL made virtualization an interesting option for the carrier grade field because it involved a reduction in costs as well as transparency in leveraging multicore equipment that runs single-core designed applications. Virtualization options also needed to meet the same expectations as the other carrier grade systems.
Carrier Grade Virtualization has tried to become a vital component to be integrated in carrier grade platforms that are already available. This is done to preserve the attributes and performance of the system. It also tries to extend the appliance target and permits Original Equipment Manufacturer (OEM) to derive the benefits from the same support as the CGL. These benefits are in the form of well established targets.
Virtualization's application is more widespread, which can be seen ranging from the x86 architecture to ARM and DSP-based processors as well as a variety of domains. The examination of virtualization from a carrier grade point of view is the focus of this solution because, in this way, you can get a clearer perspective of the areas that require improvements. In this way, these can be identified and enhancements can also be applied as required. Unfortunately, this initiative has not been as exposed as some other ones, but is still a very good source of documentation and is available from virtualLogix at http://www.linuxpundit.com/documents/CGV_WP_Final_FN.pdf. I hope you enjoy its content.
is also a Linux Foundation workgroup. It is newly formed and tries to offer an open source solution that has automotive applications. Its primary focus is the In-Vehicle-Infotainment sector, but it includes telematics systems and instrument clusters. It efforts are based on open source components that are already available. These are suitable for its purposes and try to also enable rapid development, which is much needed in this industry.
The goals of the workgroup are:
- A transparent, collaborative, and open environment for involved elements.
- A Linux operating system stack that is focused on automotives and uses the open source community represented by exponents, such as developers, academic components, and companies as back support.
- A collective voice for interaction in the open source community released this time in the reverse form, from the AGL to the community.
- An embedded Linux distribution used for fast prototyping.
By using projects, such as Tizen, as the reference distribution and having projects, such as Jaguar, Nissan, Land Rover, or Toyoto, this project is interesting enough to be followed closely. It has just been developed but has potential for improvements. For those of you interested in it, refer to https://www.linuxfoundation.org/collaborate/workgroups/automotive-grade-linux. The project's wiki page is an interesting resource and can be consulted at https://wiki.automotivelinux.org/.
The recent development of CGL made virtualization an interesting option for the carrier grade field because it involved a reduction in costs as well as transparency in leveraging multicore equipment that runs single-core designed applications. Virtualization options also needed to meet the same expectations as the other carrier grade systems.
Carrier Grade Virtualization has tried to become a vital component to be integrated in carrier grade platforms that are already available. This is done to preserve the attributes and performance of the system. It also tries to extend the appliance target and permits Original Equipment Manufacturer (OEM) to derive the benefits from the same support as the CGL. These benefits are in the form of well established targets.
Virtualization's application is more widespread, which can be seen ranging from the x86 architecture to ARM and DSP-based processors as well as a variety of domains. The examination of virtualization from a carrier grade point of view is the focus of this solution because, in this way, you can get a clearer perspective of the areas that require improvements. In this way, these can be identified and enhancements can also be applied as required. Unfortunately, this initiative has not been as exposed as some other ones, but is still a very good source of documentation and is available from virtualLogix at http://www.linuxpundit.com/documents/CGV_WP_Final_FN.pdf. I hope you enjoy its content.
development of CGL made virtualization an interesting option for the carrier grade field because it involved a reduction in costs as well as transparency in leveraging multicore equipment that runs single-core designed applications. Virtualization options also needed to meet the same expectations as the other carrier grade systems.
Carrier Grade Virtualization has tried to become a vital component to be integrated in carrier grade platforms that are already available. This is done to preserve the attributes and performance of the system. It also tries to extend the appliance target and permits Original Equipment Manufacturer (OEM) to derive the benefits from the same support as the CGL. These benefits are in the form of well established targets.
Virtualization's application is more widespread, which can be seen ranging from the x86 architecture to ARM and DSP-based processors as well as a variety of domains. The examination of virtualization from a carrier grade point of view is the focus of this solution because, in this way, you can get a clearer perspective of the areas that require improvements. In this way, these can be identified and enhancements can also be applied as required. Unfortunately, this initiative has not been as exposed as some other ones, but is still a very good source of documentation and is available from virtualLogix at http://www.linuxpundit.com/documents/CGV_WP_Final_FN.pdf. I hope you enjoy its content.
In the Poky reference system, support is provided for the development of LSB and LSB compatible applications. Inside Poky, there is a special poky-lsb.conf distribution policy configuration that is defined in case a distribution is interested in developing applications that are LSB-compliant. This holds true when generating a Linux distribution that is LSB-compliant or at least prepares to take the LSB certification. The build steps required for a Linux distribution that prepares for an LSB certification will be presented here. In case you are interested in developing LSB-compliant applications, the process is simpler and will also be briefly presented here; however, it is in contrast to the former.
Next, the build directory needs to be created:
You can also use the following command:
If various tests are not passing, the system needs to be reconfigured to ensure the required compatibility level. Inside meta/recipes-extended/images, besides the core-image-lsb.bb recipes, there are also two similar recipes:
core-image-lsb-sdk.bb: It includes ameta-toolchainand the necessary libraries and development headers that are needed to generate an SDK for application developmentcore-image-lsb-dev.bb: It is suitable for development work on targets since it includesdev-pkgs, which exposes the necessary headers and libraries for image-specific packages
meta-cgl-common: It is the focus place of the activity and the subdirectory that offers support for machines available inside poky, such asqemuarm,qemuppc, and so on.meta-cgl-fsl-ppc: It is a subdirectory that defines BSP-specific support. Such layers should be made available if the support for other machines is required.
The layer also exposes a CGL-compliant operating system image. This image tries to include various CGL-specific requirements for starters, and intends to grow by including all the requirements defined in the CGL specification document. Besides the resultant Linux operating system that will be compliant with the CGL requirements and is ready for the CGL certification, the layer also tries to define a CGL-specific testing framework. The task may seem similar to the one required for the LSB checking compliance, but I assure you it is not. It not only requires a CGL-specific language definition that has to be made according to the defined specifications, but also a number of tests definitions that should be in sync with what the language defines. Also, there are requirements that could be met with one package or the functionality of a package and these things should be gathered together and combined. There are various other scenarios that can be interpreted and answered correctly; this is a condition that makes the testing of CGL a hard task to accomplish.
Inside the meta-cgl layer, there are recipes for the following packages:
To make sure that the Heartbeat daemon is useful, it needs to be put together with a Cluster Resource Manager (CRM), which is the component responsible for starting and stopping various services to obtain a highly available Linux system. This CRM was called Pacemaker and it was unable to detect resource-level fails and was only able to interact with two nodes. In time, it evolved, and it now has better support and additional user interfaces available. Some of these services are as follows:
- crm shell: It is a command-line interface realized by Dejan Muhamedagic to hide the XML configuration and help with interactions.
- The high availability web console: It is an AJAX frontend
- Heartbeat GUI: It is an advanced XML editor that offers a lot of relevant information
- Linux Cluster Management Console (LCMC): It started as DRBD-Management Console (DRBD-MC) and is a Java platform that is used for the management purposes of Pacemaker.
Cluster Glue is a set of libraries, utilities, and tools used in conjuncture with Pacemaker/Heartbeat. It is the glue that basically puts everything together between the cluster resource manager (I am referring to Pacemaker) and the messaging layer (which could be Heartbeat). It is now managed as a separate component by the Linux-HA subproject, although it started as a component of Heartbeat. It has a number of interesting components:
- Local Resource Manager (LRM): It acts as an interface between Pacemaker and the Resource Agent and is not cluster-aware. Its tasks include the processing of commands received from the CRM, passing them to the resource agent, and reporting these activities.
- Shoot The Other Node In The Head (STONITH): It is a mechanism used for the purpose of node fencing by making a node that is considered dead by a cluster so that it can be removed from it and prevent any interaction risks.
- hb_report: It is an error reporting utility often used for bug fixing and isolation problems.
- Cluster Plumbing Library: It is a low-level intercluster communication library.
The next element is the Corosync cluster engine. It is a project derived from OpenAIS, which will be presented shortly. It is a Group Communication System with a set of features and implementations that try to offer high-availability support and is licensed under BSD. Its features include the following:
- An availability manager for the restarting of an application in case of failure.
- A quorum system that notifies about the state of a quorum and whether it's been achieved or not.
- A closed process group communication model with support for synchronization to replicate state machines.
- A configuration and statistics database that resides in the memory. It provides the ability to receive, retrieve, set, and change various notifications.
Next, we'll take a look at OpenAIS. It is the open implementation for Application Interface Specification (AIS) provided by Service Availability Forum (SA or SA Forum as it is also called). It represents an interface that provides high-availability support. The source code available in OpenAIS was refactored over time in OpenAIS and only remained SA Forum-specific APIs and in Corosync. It was also placed in all the core infrastructure components. OpenAIS is very similar to Heartbeat; it is, in fact, an alternative to it, which is industry standard-specific. It is also supported by Pacemaker.
Next is the ocfs2-tools package. It is a collection of utilities that enable the work to be done with the OCFS2 filesystem in the form of creating, debugging, repairing, or managing it. It includes tools that are very similar to the ones a Linux user is accustomed to, such as mkfs.ocfs2, mount.ocfs2 fsck.ocfs2, tunefs.ocfs2, and debugfs.ocfs2.
Oracle Cluster File System (OCFS) was the first shared disk filesystem developed by Oracle and was released under GNU General Public License. It was not a POSIX compliant filesystem, but this changed when OCFS2 appeared and was integrated into the Linux kernel. In time, it became a distributed lock manager capable of providing both high availability and high performance. It is now used in a variety of places, such as virtualization, database clusters, and middleware, and appliances. These are some of its most notable features:
- Optimized allocations
- REFLINKs
- Metadata checksums
- Indexed directories
- Extended attributes per inode
- User and group quotas
- Advanced security, such as SELinux and POSIX ACLs support
- Cluster-aware tools such as the ones mentioned previously and include mkfs, tunefs, fsck, mount, and debugfs
- In-built Clusterstack with a Distributed Lock Manager
- Journaling
- Variable block and cluster size
- Buffered, memory mapped, splice, direct, asynchronous I/Os
- Architecture and endian neutral
The lksctp-tools package is a Linux user space utility that includes a library and appropriate C language headers for the purpose of interaction with the SCTP interface. The Linux kernel has had support for SCTP since the 2.6 release, so the existence of the user space compatibility tools is no surprise for anyone. Lksctp offers access to the SCTP socket-based API. The implementation is made according to the IETF Internet draft available at http://tools.ietf.org/html/draft-ietf-tsvwg-sctpsocket-15. It provides a flexible and consistent method of developing socket-based applications that takes advantage of Stream Control Transmission Protocol (SCTP).
SCTP is a message-oriented transport protocol. As a transport layer protocol, it runs over IPv4 or Ipv6 implementations and besides the functionality of TCP, it also provides support for these features:
These special features are necessary for industry carrier graded systems and are used in fields such as telephony signaling.
Now, I will change the pace a bit and explain monit, a very small yet powerful utility to monitor and manage the system. It is very useful in automatic maintenance and repairing Unix systems, such as BSD distribution, various Linux distributions, and other platforms that can include OS X. It can be used for a large variety of tasks ranging from file monitoring, changes in filesystems, and interaction with event processes if various thresholds were passed.
It is easy to configure and control monit since all the configurations are based on a token-oriented syntax that is easy to grasp. Also, it offers a variety of logs and notifications about its activities. It also provides a web browser interface for easier access. So, having a general system resource manager, which is also easy to interact with, makes monit an option for a carrier graded Linux system. If you are interested in finding more about it, access the project's website at http://mmonit.com/monit/.
OpenIPMI is an implementation of Intelligent Platform Management Interface (IPMI) that tries to offers access to all the functionalities of IPMI and also offers abstractions for easier usage. It is comprised of two components:
There are some of packages that also should be present in the meta-cgl layer, but at the time of writing this chapter, they were still not available there. I will start with mipv6-daemon-umip, which tries to provide data distribution for Mobile Internet Protocol version 6 (MIPv6) daemons. UMIP
is an open source Mobile IPv6 stack for Linux based on MIPL2 and maintains the latest kernel versions. The packages is a set of patches for MIPL2 by the UniverSAl playGround for Ipv6 (USAGI) Project, which tries to offers industry ready quality for IPsec (for both IPv6 and IPv4 options) and IPv6 protocol stack implementations for the Linux system.
Another interesting project is evlog, a Linux Event Logging system
for Enterprise-class systems. It also is compliant with POSIX standards and provides logging for a variety of forms that range from printk to syslog as well as other kernel and user space functions. The output events are available in a POSIX-compliant format. It also offers support while selecting logs that match certain defined filters or even register a special event format. These can only be notified about when the registered event filter is met. Its features certainly make this package interesting and are available at http://evlog.sourceforge.net/.
There are a number of other packages that could be included into the meta-cgl layer. Taking a look at the registered CGL distribution could help you understand the complexity of such a project. For easier access to this list, refer to http://www.linuxfoundation.org/collaborate/workgroups/cgl/registered-distributions in order to simplify the search procedure.
To interact with the meta-cgl layer, the first necessary step would be to make sure that all the interdependent layers are available. The latest information about how to build a carrier graded compatible Linux image is always available in the attached README file. I've also given you an example here for purpose of demonstrating it:
Next, the build directory needs to be created and configured:
Inside the conf/bblayers.conf file, these are the layers that need to be added:
Having all these place, the build process can start. The necessary command for this is: