cfe2cos, the mega-merge
Summary of this Pull Request (PR)
The cFE is a complex piece of software, consequently our support implementation is quite complex. I will attempt to summarize what is going on with each change.
cFE_booter Support Code
- Summary: To get from
cos_initto the actual cFE is a bit of code, most of which is inspired by the posix implementation. We need to set up all of our data structures, start our scheduler, and make sure the filesystem is in good order. It's spread across of few files -- but again, not too complicated. We also boost the stack size so that the cFE doesn't blow the small stack. You can trace configuration logic fromcFE_entrypoint.cThe only other interesting stuff is incFE_util.c. - Component files:
cFE_booter/cFE_entrypoint.ccFE_booter/cFE_util.ccFE_booter/cFE_util.hparts ofcFE_booter/osapi.candcFE_booter/ostask.cinclude/shared/consts.h - Known Issues: The first code we wrote. It's a bit overly complex and stupid. It's written in a very formal style, which we quickly diverged from.
General OSAL Method Implementations
- Summary: The most straightforward of the straightforward. Some of these are a bit hacky, but the code quality is fine. Many of these methods are irrelevant and unimplemented.
- Component files:
cFE_booter/osapi.ccFE_booter/psp.ccFE_booter/ostimer.ccFE_booter/osnetwork.c - Known Issues:
Copied Files
- Summary: Shared OSAL code we just copied out of the cFE. Unmodified, doesn't need review.
- Component files:
cFE_booter/cfe_psp_* - Known Issues:
App Loading
- Summary: Code to work as glue between how the cFE thinks of apps, and how composite thinks of components. Method glue code found elsewhere.
- Component files:
cFE_booter/osloader.c - Known Issues: Creating a new app is a bit of a janky process.
cFE Tasks + Scheduling
- Summary: My baby. Glue for making the cFE task API compatible with composite threads. Relies on a lot of sl code under the hood. Probably needs checking for races.
- Component files:
cFE_booter/ostask.ccFE_booter/ostask.hcFE_booter/sl_mod_fprr.ccFE_booter/sl_mod_policy.hcFE_booter/sl_thd_static_backend.c - Known Issues: The semaphore implementation is pure garbage. (Luckily they're not really used.) We should talk about zero allocation semaphores.
OSAL Filesystem APIS
- Summary: This is all Joe's doing, he'll leave a comment on it.
- Component files:
cFE_booter/osfiles.ccFE_booter/osfilesys.ccFE_booter/osfilesys.hcFE_booter/tar.ccFE_booter/tar.h - Known Issues:
Queue Implementation
- Summary: Zach's doing. Not much interesting here, and I haven't looked at it in a long time. Appears to work fine.
- Component files:
cFE_booter/osqueue.c - Known Issues:
Major Build System Changes
- Summary: Integrating the cFE under composite took a bit of
makewrangling. We kept most of our original build logic--in python--but it now runs totally under composite'smake. I think most of the custom stuff is well commented. - Component files:
.gitignore.gitmodulessrc/Makefileextern/make.py - Known Issues: Half of it is in python. My
makefoo is weak, so some of this is a bit of a cludge. I just don't know how to do it better.
cFE App Component Wrappers
- Summary: We wrap every cFE app in a component, and each of these components needs a little bit of helper code. Lots of mostly unavoidable code duplication.
- Component files:
no_interface/sch_lab/*no_interface/sample_lib/*no_interface/sample_app/* - Known Issues:
cFE emulation for apps
- Summary: We need to provide a way for apps to call into the cFE, but intercepting the calls and writing parts into shared memory.
- Component files:
src/components/Makefile.compcFE_booter/cFE_emu_support.clib/cFE_emu.clib/Makefileinclude/cFE_emu.h - Known Issues: I've just realized that this should've been done through c stubs. I'll fix that, so don't bother commenting about it.
cFE_booter Build System
- Summary: The cFE booter needs some some special build logic. It isn't anything too complicated, just integrating a few external object files.
- Component files:
cFE_booter/.gitignorecFE_booter/Makefile - Known Issues:
Running the cFE
- Summary: These are our runscripts and Vagrantfile, how the cFE actually gets going. Not that interesting or important.
- Component files:
tools/Vagrantfilerunscripts/cFE_booter.shrunscripts/llboot_cFE.sh - Known Issues:
Other Outstanding Issues
- The cFE unit tests are currently broken. This probably should be fixed, but I'm unsure how much work it is. Likely can be done after the deadline.
-
llbooter/boot_deps.handllbooter/llbooter.care modified to map an extra page per component. This sucks, but without it the cFE breaks. - A bunch of stub files are changed. (As well as
include/cos_asm_simple_stacks.h) This is because their composite versions are utterly broken and don't respectconsts.h. I don't implement the most elegant solution, but w/e.
Intent for your PR
Choose one (Mandatory):
- [ ] This PR is for a code-review and is intended to get feedback, but not to be pulled yet.
- [x] This PR is mature, and ready to be integrated into the repo.
Reviewers (Mandatory):
(Specify @<github.com username(s)> of the reviewers. Ex: @user1, @user2) @gparmer @base0x10 @phanikishoreg
Code Quality
As part of this pull request, I've considered the following:
- [ ] Comments adhere to the Style Guide (SG)
- [x] Spacing adhere's to the SG
- [x] Naming adhere's to the SG
- [x] All other aspects of the SG are adhered to, or exceptions are justified in this pull request
- [x] I have run the auto formatter on my code before submitting this PR (see doc/auto_formatter.md for instructions)
- [x] I've made an attempt to remove all redundant code
- [x] I've considered ways in which my changes might impact existing code, and cleaned it up
- [x] I've formatted the code in an effort to make it easier to read (proper error handling, function use, etc...)
- [x] I've commented appropriately where code is tricky
- [x] I agree that there is no "throw-away" code, and that code in this PR is of high quality
Testing
I've tested the code using the following test programs (provide list here):
- the cFE
@gparmer Tried my best to summarize everything. Let me know if I missed anything important out.
@RobertGiff You should likely have a look at the build system stuff to see if it is compatible with the RK stuff.
I've addressed most of the above comments, will investigate the others. I also got rid of the cFE_emu library, and used the existing c_stubs mechanism.
@gparmer In terms of review ordering, this order would be great:
- cFE_booter Support Code
- cFE Tasks + Scheduling
- General OSAL Method Implementations
- cFE emulation for apps (now with c_stubs!)
- Queue Implementation
Otherwise the original order of the summaries is a proxy for my desire to have that part reviewed. (Although, I think the filesystem should go last. It's already been reviewed after all.)
Thanks!