search

nasa / cFE

The Core Flight System (cFS) Core Flight Executive (cFE)
Apache License 2.0
413 stars 202 forks source link

Implement "CFE_ES_GetVersion()" function #1176

Open jphickey opened 3 years ago

jphickey commented 3 years ago

Is your feature request related to a problem? Please describe. As in nasa/osal#821 it is preferable to obtain version strings via an API call rather than as a macro, because of how/where it is evaluated.

Describe the solution you'd like Implement API calls that return the version strings currently defined as macros in cfe_version.h

Additional context See nasa/osal#821.

Requester Info Joseph Hickey, Vantage Systems, Inc.

jphickey commented 3 years ago

Thinking about this a bit, at first I was just thinking to put this info in ES, but if the direction is to ultimately make all core apps into separate modules - so ES, EVS, SB, TBL, TIME, FS will all need separate implementations of this. They will be the same thing initially, but to be correct, this is a bit more work here. (6x to be exact).

astrogeco commented 3 years ago

Extrapolating long-term this begs the questions:

  1. Will every module have it's own version?
  2. If each module is "independent" then should we keep them in separate repos?

We might want to sit back and think about this a bit

skliper commented 3 years ago
  1. Will every module have it's own version?

Every module linked to create cFE should report version, but it doesn't have to be different (we supply all the default/supported modules as part of cFE)

  1. If each module is "independent" then should we keep them in separate repos?

No, we supply a single consistent set and call it "cFE"

We might want to sit back and think about this a bit

Happy to chat/splinter, but this would need to happen ASAP. Caelum is closing out.

jphickey commented 3 years ago

Extrapolating long-term this begs the questions:

1. Will every module have it's own version?

2. If each module is "independent" then should we keep them in separate repos?

It's perfectly fine (I think) to manage all the "core" modules together in the same repo, and have them all report the same version. But we are already allowing users to override certain modular components now - namely msg and sbr stuff.

If there is a requirement that dependent code/apps be able to obtain the version number of its environment at runtime - then it only makes sense that each replaceable component independently reports its version. This way if a mission chooses to override that component - they can identify at runtime that they are running their customized version instead of the default framework version of that component.

That being said when you add in the "numeric" version numbers that we also need to know in certain cases, this means we report 5 different versions for everything:

  1. The short/basic string, e.g. v6.8.0-rc1+dev348
  2. The code name, e.g. Bootes
  3. The full descriptive string, e.g. cFE DEVELOPMENT BUILD v6.8.0-rc1+dev348 (Codename: Bootes), Last Official Release: cfe v6.7.0
  4. The semantic version as integers, e.g. 6, 8, 0, 0
  5. The build number as an integer, e.g. 348

If every replaceable module has to report all 5 of these, and we are moving toward full modularity, then this is definitely a scaling issue here. With ~16 different modules (by my count, and growing) that means 80 different version blobs.

skliper commented 3 years ago

Thinking about this a bit, at first I was just thinking to put this info in ES, but if the direction is to ultimately make all core apps into separate modules - so ES, EVS, SB, TBL, TIME, FS will all need separate implementations of this. They will be the same thing initially, but to be correct, this is a bit more work here. (6x to be exact).

Yeah, seems like this is blowing up a bit. Maybe push to post Caelum to give us more time?

jphickey commented 3 years ago

I guess the big question here is whether its sufficient to simply report the version itself, or if it needs to implement a method where dependencies can also obtain/act on this info.

If the requirement is simply to report but not make it available up the stack - then cfe_version.h can become a private header.

If the requirement is to also make it available up the stack for dependencies - then I agree this needs more consideration.

skliper commented 3 years ago

Our requirement is to report. I think available up the stack is future-proofing (if someday modules/apps check at runtime for support). I see this as a "nice-to-have".

astrogeco commented 3 years ago

It's perfectly fine (I think) to manage all the "core" modules together in the same repo, and have them all report the same version. But we are already allowing users to override certain modular components now - namely msg and sbr stuff.

The monorepo approach for cFE works for us but wouldn't it force a clone-and-own approach for anyone who wants to customize a module?

skliper commented 3 years ago

It's perfectly fine (I think) to manage all the "core" modules together in the same repo, and have them all report the same version. But we are already allowing users to override certain modular components now - namely msg and sbr stuff.

The monorepo approach for cFE works for us but wouldn't it force a clone-and-own approach for anyone who wants to customize a module?

No. We've got examples for out of tree modules.

jphickey commented 3 years ago

The monorepo approach for cFE works for us but wouldn't it force a clone-and-own approach for anyone who wants to customize a module?

No - because of CMake. They put their customized version in the search path and it will be used instead of the default framework version of that module. They clone and own the module, but just that module, not the whole framework.

astrogeco commented 3 years ago

The short/basic string, e.g. v6.8.0-rc1+dev348 The code name, e.g. Bootes The full descriptive string, e.g. cFE DEVELOPMENT BUILD v6.8.0-rc1+dev348 (Codename: Bootes), Last Official Release: cfe v6.7.0 The semantic version as integers, e.g. 6, 8, 0, 0 The build number as an integer, e.g. 348

See my comment on the osal ticket, what is the benefit of reporting at this level of granularity?

jphickey commented 3 years ago

OK -- Based on discussion here and requirement to report only, I suggest this:

OSAL and PSP do need APIs - because they don't have the ability to directly report, CFE must report on their behalf. So CFE must obtain this info at runtime and report it.

But CFE itself does not need to provide API at this time - because it (and everything above it) can self-report. So we can defer this ticket or close as invalid/wontfix.