Structural changes for RK side of things in rump_cfe_integration

[phanikishoreg]

Summary of this Pull Request (PR)

Intention of this PR is to provide information to Henry about new changes in RK including directory structures etc.

Core RK related changes:

1. I've removed a useless components/interface/netbsd and implementation directory that contains different applications in there.. This structure seems fundamentally wrong. Because applications don't implement interfaces and if they did, we could have them in there. But the RK applications don't. I've moved different RK applications to components/implementation/no_interface. This is also how cFE does structure its applications too, so it's a consistency thing too.

2. I think there was a use of hardcoded SPDID and that a RK application had to be in a prescribed slot in the runscript. I removed this hack. Instead I've a list of application names in RK constants array and RK on initialization checks to see if any application with that name is present in the system using an hypercall interface that returns SPDID of a component that matches a 8byte name (again cFE uses this API, created by Gregor!).

3. runapps.sh changes and multi-apps I've modified RK in general to be able to run multiple apps as multiple threads in the same same lwp context of RK (this has a limitation of shared file-descriptors, etc) but we can investigate and improvise if need be.
   The way this works is, in runapps, we create multiple stubs (upto 8 supported by RK) based on the input parameters for ex: ./runapps.sh iperf creates just one stub and combines rump and cos objects and uses iperf_rumpboot.sh script. for ./runapps iperf udpservit creates 2 stubs so 2 mains in rump object and uses iperf_udpserv_rumpboot.sh script for running the system. Another thing to note is, on the RK side, we use cmdline from json string to detect the number of APPs running and importantly, rk when does create threads use that as "bt_name" thread name for bmk thread instead of standard "lwp" as the name. This is useful on cos side of RK to detect spdids. All of this feels bug-prone or at least too manual to get one setup of an app or multiple apps working. We can talk about other better ways to make this less tedious if that's useful in any way! Or I could be missing a big picture of how it can be a limitation in some cases and that this solution will not work even if we were to do it manually.

4. I've not put much time into this but components/interface/rk/ has some .h files that are not interfaces at all. like rumpcalls.h, etc. These could be cleaned up further.

Other changes

1. capmgr cleanup for tls code from Robbie. Moved initialization to a separate function.
2. Async communication library for RK and is now in components/interface/rk/rk_acom_lib.h
3. Added more system calls like getsockopt, connect, close.
4. Cleaned up RK interface, interfaces are very specific to serializing and deserializing arguments from shared memory. So added another rk_inv.h that is close to POSIX layer system call prototypes and that internally calls down to rk.h!
5. cleaned up rk interface and implementation to use a wrapper for shared page allocation instead of duplicating code for that in every function across rk.h interface.
6. Removed hardcoded flags in open and in iperf call to setsockopt. To remove hard coded flags in system calls, created mapping functions that maps musl flag numbers to rk or netbsd flag numbers.
7. cFE side of things!
8. components/implementation/rk/dummy - This is a stub implementation that is for cross-component async communication from ex: cFE to RK or for an RK app running on a different core than RK itself because we don't have support in RK (at least not investigated/not clear??) for multi-core.

I've very little confidence in the code adherence to CSG, so not ticking any checkbox for now.

Intent for your PR

Choose one (Mandatory):

• [x] This PR is for a code-review and is intended to get feedback, but not to be pulled yet.
• [ ] This PR is mature, and ready to be integrated into the repo.

Reviewers (Mandatory):

@hjaensch7

Code Quality

As part of this pull request, I've considered the following:

Style:

• [ ] Comments adhere to the Style Guide (SG)
• [ ] Spacing adhere's to the SG
• [ ] Naming adhere's to the SG
• [ ] All other aspects of the SG are adhered to, or exceptions are justified in this pull request
• [ ] I have run the auto formatter on my code before submitting this PR (see doc/auto_formatter.md for instructions)

Code Craftsmanship:

• [ ] I've made an attempt to remove all redundant code
• [ ] I've considered ways in which my changes might impact existing code, and cleaned it up
• [ ] I've formatted the code in an effort to make it easier to read (proper error handling, function use, etc...)
• [ ] I've commented appropriately where code is tricky
• [ ] 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):

• iperf, udpserver apps.
• Was also run with rk and cFE together with one of cFE app (i42) making async calls to RK (not fully functional on cFE side though).

[gparmer]

Thanks for helping out @hjaensch7 by doing this @phanikishoreg !

[phanikishoreg]

@gparmer This one is toward getting RK into mainline, which no longer is the plan, so! I'm closing this one too.