IDE Antero Camp I Project
2110-002-622
Enable Process Developers, and Application Integrators to use OpenArbor to edit
and transform Deos Integration Tool, IOI, and Deos Configuration Verification
Tool (CVT) XML files.
Description
This project will build upon the work accomplished in Antero Base Camp by: 1) Resolving Base Camp short-cuts and 2) Adding new feautres (e.g., fly-over help, wizards, custom/filtered views, improved load list & target management).
Other items have been moved off until a future release (see IDE_Ideas_Project).
Status
| Milestones | Due Date | Estimated Delivery | Delivered | Percentage Complete | Estimate |
|---|---|---|---|---|---|
| [1] HotDish Enhancements | 08-FEB-10 | TBD | TBD | 0% | 648 |
| [2] Ludefisk Ehancements | 14-ARP-10 | TBD | TBD | 0% | 560 |
| [2] Stella Ehancements | 14-JUL-10 | TBD | TBD | 0% | 400 |
Tasks for Milestone [1]
| Task | Dependency | Assignee | Original Estimate | Elapsed | Remaining |
|---|---|---|---|---|---|
| 1.1 Load List Enhancements/Load List View | None | Josh | 200 | 0 | 120 |
| 1.2 Status Monitor and XML editor User's Guides (DTD->Schema). | None | Gary | 120 | 0 | 0 |
| 1.3 Launch Button for DESK command shell | None | Josh | 8 | 0 | 1 |
| 1.4 Time Map | Eclipse GEF Knowledge | Jordan | 200 | 0 | 200 |
| 1.5 Ensure XML Builder manages multiple targets properly | None | Gary | 24 | 0 | 0 |
| 1.6 Enhance the command line Deos Integration Tool to report additional data. | None | Gary | 16 | 0 | 0 |
| 1.7 Get Deos Executable project to build all variants of an executable (SCAT, debug..). | None | Lisa | 80 | 0 | 120 |
| Totals | 648 | 0 | 441 | ||
Milestone 1 task details
1.1 Load List Enhancements/Load List View
The load list is currently a virtual entity within the deos.common plugin. Its content (as described in the Deos Project Guide) is formed from the contents of the basecon.hyp file plus any file in Deos registry scope that has the decorator 'deos-load-list' attached to it. Any changes to the deos load list (decorator modification or edits of the basecon.hyp file) trigger a listener in the load list model, which then notifys any registered listeners that the load list content has changed. The current listeners are the DeosLoadListView and the some view within the target manager.
The model/listener stuff is conceptually right, but the use of a decorator to be load list state is broken, as a C/C++ recompile of an executable will first erase that executable, thereby removing it from the load list.
The next most broken thing in the load list feature is the use of the basecon.hyp file. We needed a way to add files to the load list that would otherwise not natively be found in any Eclipse project. The kernel, network process, status monitor process, debugger, etc. all need to be on the target, and the user needs a clean and intuitive way to add/remove Deos middleware. Right now, we are telling users to edit basecon.hyp. Although this is pretty straight forward, it does NOT address any Deos XML files associated with the middleware component. Said another way, the load list manages the files on the target filesystem, but it does not configure any of those files to execute. It is the Deos registry that enables an executable file in the file system to be loaded and started. If, for example, a user wanted to integrate the AFDX driver, they would currently have to get afdx.exe onto the load list (by either editing basecon.hyp or by importing afdx.exe into a project where it could be r-clicked and added to the deos load list). The user would then also have to import the XML into a project that is registry build scope. It seem overly complicated. It would be nice if there was the option to see all Deos supplied middleware in a list, and be able to pick which parts to include -- and have that capability manage the XML as well.
Depending on how a solution here manifests, the Deos Load List View may be impacted, deprecated, or part of the solution. It was thought at one time that the Deos Load List View needed to be enhanced as follows:
- Add the ability to remove item from the load list
- Add the ability to filter the view by target
- Add the ability to edit the kernel file system name for a file
- Add the ability to sort on the columns.
- Must handle all load list sources (basecon.hyp, decorators)
[e] enhancement [b] bug
We must fix the bugs. Also consider DDCI_PCR:478
1.1.1
[e] Add check to ensure: Each binary item on the load list should be binary compatible with the containing platform project
Trivial, as long as we have the utilities objdump and readelf. We distribute GCC with Deos and in the path $(DDCIINSTALLLOC)/GCC/(i386|powerpc_elf)/bin/ we have objdump and readelf utilities.
It should be as easy as:
$ readelf -h ../../ppc/appbin/libkernel.so | grep -i machine Machine: PowerPC
When should it be run? An item can be put on the load list without being associated with a deos target platform (or an actual deos target machine). Without much thought, it seems like the place to check is right before FTP put on the file onto the target -- that popup dialog in the target manager that updates the target load.
BC and JSW think that the check should be done as early as possible. We can check during KernelFilesSubSystem.findFilesToBeUpdated() so that only compatible exe's show up in the list, but BC suggests checking even earlier at Platform build time. He says error decorators would be nice at that point.
How do you know what the target architecture is? I don't know if there is any formal interface, but mechanically here is what I know:
1) The FTP connection to the target tells you:
$ ftp 192.168.1.6 Connected to 192.168.1.6. 220 Deos FTP Server 7.2.1-x86-release. NOT Epic file system aware.
This can be done only when connected to the target.
2) The architecture is in the platform integrator XML file, and the PI tool can tell ya:
$ pi -a pi_full_2.xml x86
This can be done at Platform build time.
Seems like a deos platform project could export a method to return architecture as ppc|x86
1.1.2
[e] Each binary on the load list should be elfchk'ed to ensure its dependencies are also on the load list.
Probably the easiest task here. Its a one-liner!
See elfchk -?
$ elfchk -complete network.exe
.
*** ERROR: Some files in this set of file require shared objects which
are not present in the set of files.
** libkernel.so is needed by: /desk/ppc/appbin/network.exe
*** ERRORS FOUND.
$ elfchk -complete network.exe libkernel.so
. .
*** ERROR: Some files in this set of file require shared objects which
are not present in the set of files.
** libpal.so is needed by: /desk/ppc/appbin/libkernel.so
*** ERRORS FOUND.
and when all the necessary files are present....
$ elfchk -complete network.exe libkernel.so /desk/platform/mac6360/appbin/dbg/libpal.so . . . No errors found in: /desk/platform/mac6360/appbin/dbg/libpal.so (crc=0x4181a2b2; requires: libkernel.so) /desk/ppc/appbin/libkernel.so (crc=0x4181a2b2; requires: libpal.so) /desk/ppc/appbin/network.exe (crc=0x4181a2b2; requires: libkernel.so)
So, this should not be too bad to do
If you do do it, we will probably be leveraging the stdout format of the utility, turning that into a formal interface. I can write a PCR against elfchk to create a new switch to provide output in a particular (interface) form in case that utility ever changes...
1.1.3
[e] The registry knows the set of .exe files it needs. Those should be on the load list. .exe files on the load list that are not in the registry are not necessary on the target.
Its valuable as it completes the load list checking. Again, we will have to invent some kind of interface. My call would be to have a DEOS REGISTRY project export a method to return an ARRAYLIST of executable names -- and let the dirt of managing the interface be local to that plugin.
As a first cut, one could grep out the names from the paltreg[d].s file, as in...
$ grep "File Name (.exe)" platreg.s .ascii "network.exe" # File Name (.exe) .ascii "deosidle.exe" # File Name (.exe) .ascii "ftpserv.exe" # File Name (.exe) .ascii "gdbserver.exe" # File Name (.exe) .ascii "inetd.exe" # File Name (.exe) .ascii "sysvstrm.exe" # File Name (.exe) .ascii "sm.exe" # File Name (.exe)
1.1.4
[e] Each generated platreg[d].bin file should be regcheck'ed and errors/markers generated accordingly. (GK: This should be done by the XML builder)
Simple, but the latest kernel we are delivering does not yet have a compatable regcheck utility.
So we can defer this one for a bit...
1.1.5
[e] Add design assurance report based on elfchk -- lvideo = levelE, etc.
When you build an executable image, the resulting design assurance is only as good as the lowest rated library linked to it. A DO178B level A auto pilot, for example, could not be certified if linked to our level E video library. The intent here was to check the design assurance level of each executable image. Problem is that design assurance data is not currently available in any form -- other that in a document in the cert archive.
punt for now.
1.1.6
[e] Need to define and use tool-to-load-list capability, so that the IOI can declare the need for buffers and formatting functions to the load list.
We know registries should go on the load list (output of the IT). we know executables should go on the load list (output of the linker). What we dont know is stuff about the output of other tools/components (like IOI, AFDX, MTL, SAL, network). It would be super if a tool could be associated with a set of expected load list content and automatically added). The IOI config tool produces an ioiConfig.cfg file -- it would be super if that make it to the load list automatically.
The answer here might be in the builder associated with the tool -- the ioi builder should know to add its output to the load list.
punt for now.
1.1.7
[b] When a project is compiled, the first thing the compiler does is delete any present .exe target. If the .exe image was on the load list, a recompile will remove it from the list.
Solved as of DDCI_PCR:495 Comment #8
1.1.8
[b] load list must be made to be case insensitive and check for duplicates in a case insensitive manner. The Deos file system is not case sensitive at this time.
Deos file system is not case sensitive. When adding to the load list, just check for dup names (maybe already in place -- if not, its a bug) in a case insensitive manner.
1.1.9
[e] Something should be done to make managing Deos supplied applications (and their configuration data) easier than editing the basecon.hyp image.
I think we had a proposal for this. Each project would have a load list property. A platform project would get its load list property initialized with the content of the basecon.hyp file. Then, we dont need no stinking HYP file.
1.2
The status monitor currently has no user's guide. Additionally, the XML editor has no documentation, but this might not be a problem if the command line tools switch from DTD technology to XML schema, as the XML editor in eclipse is believed to support schema tags which would automatically show popup help on a field by field basis.
It is believed that switching from DTD to XML Schema will enable the XML editor to provide fly-over help. The AFDX, IOI, and IT tools would need work, and minor work may be needed on the AFDX CVT an IOI CVT.
1.3
There are a number of commands that a user will want to enter into the DESK console. Right now, users have to find the shortcut on the Windows Desktop. It would be easy and convenient if there was a way to fork the command prompt from within the IDE.
1.4
This is the tool that shows Deos events in graphical form. Need some time to determine the complexity of doing graphics within Eclipse views. We have the code base -- which can be reused to construct the data model. We just need someone to write a view...
1.5
Comment from DeosXMLBuilder.java: // GK: KNOWN_LIMITATION: The IOI collects project/fp file pairs, and makes them available to the IT builder. // The problem is that if the IOI project is linked to more than one registry, I dont think both of those // registries will see the changed FP files. Find out for sure and fix as necessary.
I verified the behavior to be as desired. No problems here.
1.6
The Deos Integration Tool produces a CCK file when a registry is generate. Cronk would like to see more substance in the file, including which processes will auto-start, resource constraints per process, parent-child graphs. It could be just text in form, but it would be really nice if it was an eclipse graphical view.
1.7
When a Deos executable is built, several versions of the executable are typically built. The 'release' version for revenue-service, 'debug' version for debugging, and two 'instrumented' variants in support of the structural coverage tool SCAT. Can we get a Deos Executable project to yield all versions when the project is built?
Tasks for Milestone [2]
| Task | Dependency | Assignee | Original Estimate | Elapsed | Remaining |
|---|---|---|---|---|---|
| 2.1 Wizards to support all Deos XML types (GUI editors). | None | None | 120 | 0 | 120 |
| 2.2 Export makefile. | None | None | 80 | 0 | 80 |
| 2.3 HYP file creator | None | None | 40 | 0 | 40 |
| 2.4 Deos Project View | None | Josh | 160 | 0 | 160 |
| 2.5 Target manager usability enhancements | None | None | 160 | 0 | 160 |
| Totals | 560 | 0 | 560 | ||
Milestone 2 task details
2.1
Some discussion needs to be had on the applicability of some of the wizards listed below. Additionally, it would be best if a wizard could also perform the role of GUI editor. That is, 'editing' an XML file might just feed that XML file into the wizard. This would of course require the wizard to parse XML.
In case it matters, the switch from DTD to XSD has enabled the default XML editor to properly construct XML elements (the DTD version would not fill in all attributes correctly)
- application integrator (do we need this?) I think not for PIPC, but yes for schedule-before relationships.
- platform integrator
- feature provider (lowest priority)
- all 3 ioi types
- AFDX driver ()
- graphical sb tool ?
- graphical ioi tool ?
- option to generate source code based on wizard output ?
2.2
- For a project: (what would this mean in an environment where multiple projects go into a "build"?
- For a workspace (would we have to select which projects to include?)
- What makefile form/technology? GNU? scons? Other?
2.3
The entire content of the loadlist (the sum of the files with the load list attribute plus the contents of the basecon.hyp file) need to be written to a new basecon.hyp file where the makeboot Deos utility can bundle the contents into a single hyperstart/bootable image on a target.
2.4
This view would show all Deos projects, and organize them in tree form, with a hierarcy of projects (right now all the projects are flat, and integration is the act of modifying project references). That linking/integrating mechanism should be abstracted. Better ideas solicited.
2.5
- The target connection icon uses color to indicate state. For the color impaired, a different icon for the different states would be better. DDCI_PCR:143
- When changing modes, the FTP server is reset and the target connection is lost. The user should be given the option to auto-connect on mode changes, and the default for that option should be 'yes'. DDCI_PCR:450
- Users are confused by the seeming availability of the SM and TSVS options in DL mode where they are not typically configured to function. There is enough state information in the IDE to know if the SM and TSVS options should be made. This would fix DDCI_PCR:162,DDCI_PCR:163
- DDCI_PCR:317
- DDCI_PCR:20
Tasks for Milestone [3]
| Task | Dependency | Assignee | Original Estimate | Elapsed | Remaining |
|---|---|---|---|---|---|
| 3.1 Formalize interface between BSP and the platform wizard | None | None | 24 | 0 | 24 |
| 3.2 Toolbar button to look up error numbers (errnum.bat) and open the appropriate User's Guide. | None | None | 16 | 0 | 16 |
| 3.3 Re architect the Target manager plugin data model | None | None | 160 | 0 | 160 |
| 3.4 Add Feature Provider Files to middleware to make integration easier | None | None | 160 | 0 | 160 |
| 3.5 Integrate SCAT | None | None | 40 | 0 | 40 |
| 3.6 Target synchronization/ RSE NOOP (OA can hang) | None | None | ? | 0 | ? |
| Totals | 400 | 0 | 400 | ||
Milestone 3 task details
3.1
Currently, the platform wizard makes assumptions about a BSP content based on file names. What is needed longer term is to formalize the interface; the current thinking is a file that contains a mapping between the basecon files, the number of cores, the names of the config files to their actual physical file names. See the wizard implementation for additional details.
3.2
Deos API calls return numeric error codes which are difficult for users to interpret (visually). Typically in a debug scenario, users will write code to dump out a return code to video memory. The human has the chore of translating that number to a string in the users guide to determine what has failed. There is a Deos utility called errnum which can be used to perform this translation. It would be nice if there was direct support for that utility within the IDE.
3.3
The data model for the status monitor should be reworked into the MVC framework. The MVC model should be a background thread that has 2 copies of all Deos target data. The background thread should collect up all data and once it is available, it should notify its listeners that new data is available. This would keep all display data in sync, and would eliminate the code that polls data on GUI events (which is bogus). See DDCI_PCR:6.
This task includes the implementation of the R P V and other status monitor commands that currently have no GUI representation.
3.4
- Update all middleware to distribute .fp.xml files (ansi, math, sal, mtl, ...). AFDX, IOI, already done.
- MTL, SAL and lwIP might be complicated, as they would need to expose features that go beyond simple quota adjustments.
- Prioritize the libs in this order: ansi, math, ioi, mtl, sal, lwip, inetapi
3.5
SCAT comes with command line utilities to clear a hitmap, get a hitmap from the target, process a hitmap against a set of instrumented source code files, and generate HTML pages showing the coverage report.
- mechanism to trigger the extraction of results from target and show generated HTML pages
- mechanism to save off results into filesystem for archival
3.6
The RSE package (the foundation of the target manager) had a protocol in which the FTP client would (frequently) send NOOP FTP commands to the FTP server to determine if the server was still present. The target manager implementers, due to a design flaw, saw the NOOP commands as an undesirable interference pattern when trying to interact with the FTP server, and as such, the NOOP'ing was effectively disabled. The side effect of this is the loss of a graceful exit if the FTP server does go away (turn a target system off, for example). See DDCI_PCR:165.
