The file sw-description is the central place to configure a release and to provide how a new sofware must be installed. Apart very simple cases, an update consists oft of several parts, some of them are not always active, and a release can be installed on devices with different hardware revisions. This leads to have several sections inside sw-description. It is possible to factorize some parts of them using SWUpdate’s links. A link is a reference for one of the major sections (images, files, partitions, scripts and bootenv) and the whole section can be referenced by a link. Let’s start having a device in field, but several hardware revisions are now running and the software is not exactly the same for all of them. For example, older hardware revisions are not supported by newer Linux kernels, or new application’s features are just added to later releases due to hardware limitations. SWUpdate has always supported this case, and sw-description is omething like the following:
software =
{
version = "0.1.0";
myboard = {
stable = {
hardware-compatibility: ["1.0", "1.2", "2.0", "3.0", "3.1"];
rev-1.0: {
images: (
...
);
scripts: (
...
);
}
rev-1.2: {
hardware-compatibility: ["1.2"];
images: (
...
);
scripts: (
...
);
}
rev-2.0: {
hardware-compatibility: ["2.0"];
images: (
...
);
scripts: (
...
);
}The device should recognize which hardware revision is running, and SWUpdate is started via “selection” to parse just the relevant part of the file. A lot of entries must be duplicated, for example if most releases share the same kernel or rootfs. Using links, the example above can be written as:
software =
{
version = "0.1.0";
myboard = {
stable = {
hardware-compatibility: ["1.0", "1.2", "2.0", "1.3, "3.0", "3.1"];
rev-1x: {
images: (
...
);
scripts: (
...
);
}
rev1.0 = {
ref = "#./rev-1x";
}
rev1.2 = {
ref = "#./rev-1x";
}
rev1.3 = {
ref = "#./rev-1x";
}
rev-2x: {
images: (
...
);
scripts: (
...
);
}
rev2.0 = {
ref = "#./rev-2x";
}This factorizes big blocks, that is some blocks are common between the revisions.
Links has the following syntax:
- the attribute name is ref
- link start with the character #
- relative links can be set with :
- a single “.” : points to the current level in the tree, that means the ref”s parent
- a double “..” : points to the parent’s leven in the tree
- “/” is the separator to traverse the tree
Anyway, it was not possible until now to split one of the sections to share a common block and some specific extensions. For example, if the application consists of more entries (image and files), but depending on hardware revision or on the mode the device is started there are some entries that differ.
somecommon: {
images: (
{
.............
},
{
.......
}
)
}
somespecific: {
images: (
{
.............
},
{
.......
}
)
}
selection : {
images: (
{
ref = "#./../../somecommon/images";
},
{
ref = "#./../../somespecific/images";
},
{
filename = "somefilename";
device = "/dev/somedevice";
type = "raw";
}
)Links are now available in whole sw-description and this simplify the readability and maintainability. This feature is now commited.
