- Summary
- Add target database (aka "board dictionary") feature to fuego
; Owner: Tim
; Reporter: Tim
; Status: closed
; Priority: medium
|
; Summary: Add target database (aka "board dictionary") feature to fuego
; Owner: Tim
; Reporter: Tim
; Status: closed
; Priority: medium
|
|
|
= Description =
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.
|
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.
|
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.
|
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
|
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?
|
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 =
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?
|
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?
|
|
Update in May 2017 - dynamic variables are now placed in the file:
/fuego-rw/boards/<board>.vars. These can be erased at any time, and will
be rebuilt by tests that populate the file.
|
Update in May 2017 - dynamic variables are now placed in the file:
/fuego-rw/boards/<board>.vars. These can be erased at any time, and will
be rebuilt by tests that populate the file.
|
|
For now, ignore this issue.
|
For now, ignore this issue.
|
- backlink
Fuego Issues List
|
; backlink: [[Fuego Issues List]]
|