ARRIS Enterprises, Inc. Confidential Information

Parameter Inheritance

IIPs now offer an advanced feature for inheriting parameters and arguments. This is best illustrated using an example; Changing the Graphics Stack.

The KreaTV software has lived through several different underlying graphics stacks. This has, in the past, had big implications on the bootimage config. How do we ensure you do not have to update the boot image config because graphics stack is changed?

The Problem

Application XYZ is compiled for a specific graphics stack, let us call it KreaTV GFX. This would be represented by IIP kreatv-app-xyz depending on kreatv-option-kreatvgfx-stack. Now imagine we want to start using another graphics stack, let us call it DirectFB. But we still want KreaTV GFX to be used as the default stack in deployments. So we cannot simply change the content of kreatv-app-xyz and make it depend on kreatv-option-directfb-stack.

At the same time we, in our example, want the DirectFB stack to become the default stack in a coming release. So the majority of KreaTV boot image builders would go with the default stack and some would want to try the new stack.

The Solution

The solution to this problem is to create two new IIPs: kreatv-app-xyz-kreatvgfx and kreatv-app-xyz-directfb. You still use kreatv-app-xyz in the boot image config, but now it is simply an empty IIP depending on and forwarding its parameter values to kreatv-app-xyz-kreatvgfx. This way people wanting to try the DirectFB stack can do that by removing kreatv-app-xyz and directly include kreatv-app-xyz-directfb in the boot image config. People wanting to run the default stack will be bumped automatically to using DirectFB if/when we switch dependency to kreatv-app-xyz-directfb IIP.

One nice thing with this solution is that as long as there is no alternative and only one graphics stack for application XYZ we can keep one IIP (only kreatv-app-xyz directly depending on kreatv-option-kreatvgfx-stack). The switch can then be done when needed under the hood without having to change our external interface (i.e. the boot image configuration file).

With this solution we can also choose to use different default graphics stacks for different devices/toolchains. Simply create different kreatv-app-xyz IIPs with different dependencies for different devices/toolchains. Here's an example of how it could look:

Forwarding/inheriting parameters

So how do you inherit parameters and their values between IIPs? Simply use IIP interface property Inherit. For kreatv-app-xyz-kreatvgfx (and kreatv-app-xyz-directfb):


<IipInterface>
  ...
  <Inherit iip="kreatv-app-xyz"/>
</IipInterface>

Note that...

... the parameter lists must be exactly the same for the IIP forwarding it and the one inheriting it.
... there must be a dependency from the IIP forwarding parameters to the one inheriting them.
... deprecated parameters without new usage (i.e. has no alias set) are not forwarded between IIPs and thus do not have to be part of both parameter lists.
... having two IIPs which inherit the same IIP in a boot image config results in a build error.
... having the inherited IIP and the IIP forwarding parameters in a boot image config results in a build error.

Keeping parameter lists synced between IIPs

Since we check that parameter lists are the same for the IIP forwarding it and the one(s) inheriting it, it is a good idea to actually make sure we use the same source for parameters when building up the description.xml file making up the IIP interface. Putting them in a separate file and including it in all three (kreatv-app-webkit, kreatv-app-webkit-kreatvgfx, kreatv-app-webkit-directfb) description.xml files is the way to go.