Deos Sybil 653 OpenArbor Impact

With a goal of getting some behaviors added into OpenArbor, I've written up a problem statement for the OpenArbor team to ponder. I've attempted to explain the need using many more words than I usually do, in case that is helpful.

Overview

We are going to need some updates to OA to support a couple of new features of Deos and Deos653. These changes will impact how some of the config tools are invoked, and will require some reworking of some of the makefile rules (and assumptions). And I think we will need to define some project or file properties as well.

The new features are:

• Deos “Sybil”: Platform projects to date all have 2 registries – normal and download. Deos is no longer limited to these two personalities, but will be allowed to have more (or less). BSPs are still shipping with just the two legacy personalities, but users should be allowed to add more in OA (a New Registry Project wizard).
• Deos653: We have taken some shortcuts here where IOI files are generated by the deos653config tool, and it’s now time to address the full solution. The ability to construct multiple IOI config files, and the ability to manage the config file namespace is necessary.

OA support for Deos “Sybil”

• The ability to ‘copy’ an existing registry project to inherit existing XML, etc. Do project references get copied too? I suggest no.
• For a ‘new’ registry project, I suggest doing whatever the new platform project wizard does for a normal mode registry project and let the user adjust it from there.
• The ability to delete a registry project – that is probably already in place, but I don’t know if that confuses the target manager or not.
• The ability for the target manager to switch registries by name. Right now we have a download mode button. That probably gets replaced with a registry name combo box. The FTPServer (not yet even committed to SVN according to RR) will have a new command “quote site registry [registryname]” that will be used to switch registries. The other attributes (debug, coldstart, etc.) will retain the same interface.

Rfrost@ddci.com 19:23, 13 February 2012 (UTC) How does this impact multiple Deos baselines with single OA deliverable. Denali and possibly Elbert do not support this, while mainline does, so OA will need different logic. It can have the interface with the combo box, but selecting platreg or platregd would have to give a different command in Denali than it should in mainline.

Deos653

First, a review of the IOI workaround that in place right now. The deos653config tool generates a pile of IOI XML that is stored in the 653 projects output folder. That pile includes a .binder.xml file, which is the thing that binds inputs to outputs. Within build scope, it is also possible that there are Deos applications that do their own IOI stuff and have their own .binder.xml file. It’s also permitted for 653 binding to cross the product boundaries and interface with Deos application IOI stuff.

What we did to make all this possible in the short term was … change the ioiConfig tool to accept multiple .binder.xml files (instead of its previous limit of 1). The tool effectively combines all of the binder files into a single temp file, and then passes that temp file along as if there was still just one binder file being passed in. All OA had to do was … find all the IOI XML in build scope, and pass that pile to ioiConfig, storing a hard coded ioiConfig.cfg binary configuration file in the associated registry project. It was then up to the user to rename that configuration file via the load list if desired.

This approach has limitations:

• The name of the config file is not within user control in the OA environment, yet the name of the config file can be specified in user source code in the ioi_init(<file name>) call.
• All IOI content is wedged into a single config file. This could impact verification activities, as a known and verified set of interactions is now mixed with other applications and interactions. If one set of interactions is stable and ready for verification (or already verified), it would be best if other content is not mixed in. You get what I mean here.
• “Sybil”: When changing personalities, the IOI configuration is probably also going to change. We need to be able to create multiple configurations to support this feature. Right now, we just assume it’s normal to not have any IOI configuration in the download mode registry – that’s probably right most or all of the time, but there is nothing else except OA preventing the use of IOI features in the DL mode registry.

It’s clear to us now that there is a fixed relationship between a Deos registry, a specific 653 config file, and a specific IOI config file. The Deos registry identifies the 653 partitions to start, and the 653 configuration file name that the 653 runtime library is to load (the generated .pd.xml file from the tool places the 653 configuration file name on the ProcessInstances ARGV list). The 653 configuration file contains the name of the IOI configuration file that the runtime library will pass to the ioi_init() call.

Changing a registry can also mean changing to a new 653 setup – Deos “Sybil” can cause 653 “Sybil” as well. This is a feature in the ARINC 653 specification Part 2 – were not claiming conformance to Part 2, but this is a real nice-to-have feature that comes as a side effect.

Rfrost@ddci.com Note: Part 2 is more of a runtime module schedule change where it takes affect at the next major frame. It does not require a cold start, like Deos Sybil to use a new registry.

Given this behavioral goal, we know we need to be able to create multiple 653 config files and multiple IOI config files. The 653 part is straight forward, but the IOI part is not – as sometimes multiple binder files should be merged together into a single config file, and sometime they should not. That behavior is driven purely by the 653 user.

For a given .binder.xml file, OA must be able to know:

• What the resulting IOI config file should be called.
• Whether or not other binder files should be passed on the command line to ioiConfig (remember that the –M switch on the ioiConfig command line was put there to allow OA to pass all .formatter.xml and all .ioi.xml files in build scope to ioiConfig all the time – the only question is … how many binders)

Feel free to challenge me on this, but I say there is only one scenario in which multiple binders should be passed to ioiConfig in the OA environment, and that is when a 653 user is using hybrid-io (io between the 653 partitions and Deos processes). Everything else I have to propose is based on this invariant.

OA support for Deos653/IOI cleanup

• When there is a Deos653 XML file in a project, that file (or project, or new project type) needs to offer up some user settable properties:
  • Name of the 653 config file to generate (the –g switch to deos653config). The tool will then place this name on the ARGV attribute of the predefined process of each partition in the XML, which ends up in the Deos registry.
  • Name of the IOI config file associated with the 653 configuration (the new –i switch to deos653config). The tool will write this file name in the 653 configuration file, where the runtime library will pass it along to ioi_init().
  • Hybrid IO Boolean: when false, simply call ioiConfig with the contents found in the output folder of the project. When true, we need collect references to other projects that contain binder files. When invoking ioiconfig, pass in the contents of output plus all the binder files found in the referenced projects plus all of the .ioi.xml and .formatter.xml files found in build scope. Alternatively, if you want to manage .ioi.xml and .formatter.xml dependencies in any means, do so. Just know that the tool via –M can also manage dependencies, although not as nicely.
  • Where do the IOI config files go? They could continue to all be stored in the associated registry project, but that means the config file namespace must be managed prior to the load list checker. I don’t have a strong opinion here.
• When there is a .binder.xml file in a project, that file (or project, or new project type) needs to offer up one more user settable propery:
  • Name of the IOI config file to generate (the –g switch to deos653config)

In the hybrid-io case where there can be multiple binders, the above list of properties is of course inviting a conflict where one binder want the config file to be foo, and another binder wants the config file to be bar. A check there would have to be made to ensure all the project agree on the name prior to building – that is very important, as whatever name the user provides must also end up in their Deos process source code as the name passed into ioi_init() – it’s nice to have this check at build time.

One more note on this: When the deos653config tool populates the output folder with IOI XML, that is a case where the IOI config file name property is potentially stored in a different location/means than a Deos project with a .binder.xml file in it. In the scenario described, the 653 project provides the necessary input, but it is a difference in behavior. The only way to have a single behavior in this regard would to have OA add the properties to the .binder.xml when the IOI XML files are generated in the output folder.