Chapter 5. SCR Details

Table of Contents

5.1. SCR Agents
5.2. SCR Tree
5.3. Accessing SCR
5.4. Using SCR From Within YCP
5.5. Using SCR From The Command Line
5.6. Useful SCR Agents

In the intoductional chapter we have already heard something about accessing the system with SCR. Because manipulating the system at the lowest layer is all YaST is about, we now want to take a closer look at this topic.

Basically the SCR creates a consistent view of the system hardware and its configuration files. There are many dependencies between the different entities among those data and these dependencies have to be taken into consideration when manipulating them. For this being possible in a convenient way for the higher-level modules there must be an easy and consistent accessing method. This method is provided by the SCR as it presents kind of an abstraction of the various types of data to be handled.

Now the data “landscape” that must be covered here is rather heterogeneous. Hardware data and configuration data, both of most multifaceted type can hardly be handled by one single monolithic program. Therefore the SCR consists of a “head” that is accompanied by various helper programs, the so-called agents, each of them being specialized on a specific task.

5.1. SCR Agents

For each category of system data there is a corresponding SCR-agent. Their job is to map the real system data to YCP-data structures so that YCP-modules can access them in a convenient way. In fact the SCR-agents provide the YCP data structures. They come into existence with the presence of an SCR-agent that provides them. Otherwise they wouldn't be there.

For example there is an agent that reads and writes the /etc/sysconfig files. The YCP-representation of a sysconfig-variable is a single YCP-string. When reading, the agent reads the variable in the corresponding file and creates a YCP-string from it. When writing, the agent gets the new value as YCP-string and changes the variable in the corresponding file accordingly.

It must be said here, that the set of agents may change over time. New agents may be created in the future and other ones might be abandoned if their functionality is obsolete or taken over by another agent. Generally this is no problem because for module development it is not (and should not be) necessary to know exactly which agent does what. As already said, the SCR provides an abstraction of the data to be handled and this abstraction comes into being in form of a tree, the SCR-tree.