Summary

Add target database (aka "board dictionary") feature to fuego

Owner

Tim

Reporter

Tim

Status

open

Priority

medium

Description [edit section]

The target database holds information about a board, for use by the fuego system. The "board dictionary" holds the information for a particular board.

The information that needs to be held for a particular board depends on the tests that are installed in the system. Thus the system needs to be ad-hoc.

ftc should be used to manage the board dictionary values (like tdb). A user should be able to manually clear values, update values and read values.

The board file should be used to hold the board dictionary. The dictionary values should be kept in ENVIRONMENT variables, that are set when the board file is source'd.

Some values that should be considered "board dictionary" values are:

• SATA_DEV
• SATA_MP
• LTP_OPEN_POSIX_SUBTEST_COUNT_POS
• LTP_OPEN_POSIX_SUBTEST_COUNT_NEG
• FUNCTIONAL_BC_PROGRAM

This feature supports manual and programmatic modification of the information for a board. This supports several features:

• ability to scan a target, and add info to the file
  • for detecting test binaries
  • for assistance in installing board files (autodetect SSH_PORT, IP, TRANSPORT, PLATFORM)
• ability to add info for latest tests
  • performance baseline?

Notes [edit section]

When updating the board file, updates to existing values should replace lines in the same position in the file. (Lines should be replaced in-place, and not moved around on an edit).

Should there be an indication of whether a value should be persistent or not? Some values might change, if the software on the target changes. For example, FUNCTIONAL_BC_PROGRAM might change if the distro on the target changes, or if the program gets deleted. Should this be treated like a cache variable, instead of an immutable fact about the board? How would we indicate that?

For now, ignore this issue.

backlink

Fuego Issues List