PSP modular build enhancements

[skliper]

Currently, in order to support a different variant of a board, such as one that has the same processor but different set of peripherals, one must "clone" the entire PSP of the board and modify it to support the new board.

The problem with this approach is that as usage becomes more widespread we will end up with a large number of similar-but-different PSPs needing maintenance. Any change to the CFE that requires PSP support will require updating ALL VARIANTS of the PSP which will become increasingly difficult.

The CMake build system introduced in ticket #4 as the ability to //statically// link in a set of extra mission-defined code modules into the PSP library. With this system in place, CFS applications can bind to specific "PSP drivers" at runtime.

This is analogous to statically linking driver modules into the Linux kernel depending on the hardware configuration. As long as the interface is the same (e.g. "/dev/ttyS*"), the application need not know what hardware is actually providing the interface.

This allows code re-use in many ways:

• A single PSP can support multiple physical board variations by loading a different module set.
• Multiple PSP's can leverage the same drivers where appropriate (e.g. an ADC driver that communicates over a serial bus can work equally well on ARM, x86, or PPC as long as it has a compatible serial bus).
• As long as all similar-function PSP modules provide the same application-facing API, any CFS application implementing "business logic" can operate in a completely hardware-independent manner. The driver module can be replaced with a different module and the CFS application does not need to change (or even be recompiled) to work with alternate hardware.

This framework should help avoid the need to "clone-and-own" a PSP for a particular project. This is especially true for Linux PSPs which are already very generic (e.g. pc-linux easily runs on ARM Linux or PPC Linux). The framework is a very simple extension to the PSP and does not change existing PSP APIs so it will not interfere with existing code.

[skliper]

Imported from trac issue 3. Created by jphickey on 2014-12-26T22:30:17, last modified: 2019-04-02T14:49:34

[skliper]

Trac comment by jphickey on 2014-12-28 22:53:04:

Pushed commit [changeset:3c1183e] to address this.

Branch name is trac-3-psp_driver_framework.

[skliper]

Trac comment by glimes on 2015-01-30 11:44:29:

Now reviewing [changeset:641f577 changeset 641f577] ...

notes so far:

• Lines 94..98 of cfe_psp_iodriver_impl.h decleares a CFE_PSP_IODriver_NameList_t structure typedef, but provide no documentation; the code seems to indicate an unconventional use of const char * to contain a ''list'' of names.
• Implementations of the four functions declared in cfe_psp_iodriver_impl.h are not present within this version of the code (as far as I can find).

[skliper]

Trac comment by sduran on 2015-03-19 17:26:02:

Good idea, recommend accept.

[skliper]

Trac comment by jphickey on 2015-04-06 12:25:25:

Points brought up by Greg are valid here -- good catch, didn't notice that earlier.

The problem here is that I did not backport any driver //implementation//, only the API that defines the framework. Those functions are indeed part of the (shared) implementation and that NameList probably needs to be a pointer to pointer.

[skliper]

Trac comment by jphickey on 2015-04-06 12:32:33:

Another topic for review/discussion here is that CCSDS SOIS-App working group is actively working on a specification for hardware abstraction layers and this actually fits nicely into it, although the naming currently does not match. I believe this fits into the role of the "Subnetwork Layer" or possibly "Device Access Service" (DAS) as defined by SOIS. We could also implement SOIS electronic data sheets here as well.

[skliper]

Trac comment by glimes on 2015-04-07 12:31:53:

I've been testing changeset [changeset:d0f1e2b] as part
of the ic-2015-03-10 merge. We may need to make a quick
decision on whether to include this changeset as is, or
to exclude it from the merge, or to revise the change and
include the revised change in the merge.

[skliper]

Trac comment by jphickey on 2015-04-07 12:42:48:

My general feeling at this time is to leave it out of the regular development build for now, since nothing else really depends on it being there (except for my stuff, anyway).

I will merge this into the forthcoming "EDS preview" development branch while we figure out how much of the SOIS-App architecture specification we want to implement and how this fits into it.

[skliper]

Trac comment by glimes on 2015-04-07 14:36:59:

Will retract from the PSP ic-2015-03-10 merge.

[skliper]

Trac comment by jphickey on 2015-07-17 11:20:09:

This ticket was discussed in the 2015-07-14 CCB meeting and it will be split into two items:

1. The modifications to the PSP build to allow a more modular approach; i.e. avoiding the need to clone an entire PSP just to change one small aspect of it. This will hopefully help us avoid having a large number of mostly-similar PSP trees to test and maintain, by consolidating code modules that remain the same.

2. The API that allows higher-level code to communicate with on-board devices. This is the "driver framework" that the original ticket referred to; this will be tracked in a separate ticket, and may be related to/influenced by the CCSDS SOIS-App specifications for communication with onboard devices.

Update: Ticket #33 has been created for item 2 above.

[skliper]

Trac comment by jphickey on 2015-07-17 11:36:37:

Setting back to "in_work" as I cherry-pick those components of the original change set that focus on the modular PSP build aspect (item 1 above).

[skliper]

Trac comment by jphickey on 2015-08-10 11:29:37:

Candidate for inclusion in the next CCB review with commit [changeset:b18ea23]

This change set focuses on allowing modules to be statically linked into the PSP. This is a basis to help support different board variants without forking the entire PSP.

[skliper]

Trac comment by glimes on 2015-08-11 12:31:43:

Approve.

For the future, it strikes me that CFE_PSP_SetupEEPROM could be
made a little bit more robust in a few ways.

• When creating a new file, this only writes the last byte. On some filesystems this will create a sparse file, where storage is only allocated for the last block. Using a larger write to clear the whole extent of the file would assure that the file system allocated all of the appropriate blocks, rather than getting a sudden SIGSEGV later when first attempting to write to a previously unallocated block of the file, in the case where the backing filesystem is full. This is a rare case, hardly ever occurs, and is a royal pain to diagnose when it does, so it is probably worth following up with a ticket to do this.

• When using a preexisting file, the code presumes that it can simply mmap the expected size. This is fragile in the face of the possibility that the preexisting file may be a different size. I would recommend checking the file size ''(we have the stat output on hand, so it is easy)'' and if it is too small, extend the file size. Bearing the above in mind, proably best to do this by appending blocks of zeros to the end of the file rather than writing the last byte.

On a side note, using ftruncate to set the size has all the same problems as writing the last byte of the file, except that it does not allocate the last block, either -- we could use ftruncate to make the file smaller, but when making this file bigger ... paranoia dictates writing zeros, I think.

I suggest not holding up '''this''' ticket based on the above concerns.

[skliper]

Trac comment by glimes on 2015-08-11 12:36:03:

NOTE: requires coordinated integration of the [cfs_cfe:84] changes.

[skliper]

Trac comment by jphickey on 2015-08-17 11:54:12:

== REBASE ==

This has been rebased to the current CCB-approved merge (ic-2015-08-10 branch).

Updated commits: [changeset:dc4760f] (basic change), [changeset:454501d] (eeprom proof-of-concept)

[skliper]

Trac comment by aangie on 2015-08-25 14:25:22:

accept

[skliper]

Trac comment by glimes on 2015-09-08 14:01:32:

Merged to development.

[skliper]

Trac comment by glimes on 2016-01-11 10:42:10:

Mark for PSP 1.3 per email from sstrege

[skliper]

Trac comment by jhageman on 2019-04-02 14:49:34:

Milestone renamed