brians | 343bc11 | 2013-02-10 01:53:46 +0000 | [diff] [blame] | 1 | see ../README.txt for overall information |
| 2 | |
| 3 | [FILES] |
| 4 | config/ has some configuration files |
| 5 | aos.conf has directions for setting up resource limits so you can run the code on any linux machine (the directions are there to keep them with the file) |
| 6 | setup_rc_caps.sh is a shell script (you have to run as root) that lets you run the realtime code without installing aos.conf for an individual file |
| 7 | starter is an init.d file |
| 8 | install it by putting it in /etc/init.d an running "update-rc.d starter defaults" |
| 9 | restart it by running "invoke-rc.d starter restart" (doesn't always work very well...) |
| 10 | the .config files are for building linux kernels |
| 11 | |
Brian Silverman | 14fd0fb | 2014-01-14 21:42:01 -0800 | [diff] [blame] | 12 | linux/ has code that only runs on linux systems |
brians | 343bc11 | 2013-02-10 01:53:46 +0000 | [diff] [blame] | 13 | |
Brian Silverman | 20141f9 | 2015-01-05 17:39:01 -0800 | [diff] [blame] | 14 | common/ is where stuff that runs on all platforms is |
brians | 343bc11 | 2013-02-10 01:53:46 +0000 | [diff] [blame] | 15 | common/input/ is where the framework code for reading stuff into the queues system is |
| 16 | common/output/ is where the framework for writing things out of the queues system is |
| 17 | common/messages is where the c++ wrappers for "queues" are |
| 18 | |
| 19 | [NOTES] |
brians | 343bc11 | 2013-02-10 01:53:46 +0000 | [diff] [blame] | 20 | Some functions need to be in separate translation units in order for them to be guaranteed to work. As the C standard says, |
| 21 | Alternatively, an implementation might perform various optimizations within each translation unit, such |
| 22 | that the actual semantics would agree with the abstract semantics only when making function calls across |
| 23 | translation unit boundaries. In such an implementation, at the time of each function entry and function |
| 24 | return where the calling function and the called function are in different translation units, the values of all |
| 25 | externally linked objects and of all objects accessible via pointers therein would agree with the abstract |
| 26 | semantics. Furthermore, at the time of each such function entry the values of the parameters of the called |
| 27 | function and of all objects accessible via pointers therein would agree with the abstract semantics. In this |
| 28 | type of implementation, objects referred to by interrupt service routines activated by the signal function |
Brian Silverman | 14fd0fb | 2014-01-14 21:42:01 -0800 | [diff] [blame] | 29 | would require explicit specification of volatile storage, as well as other implementation-defined |
brians | 343bc11 | 2013-02-10 01:53:46 +0000 | [diff] [blame] | 30 | restrictions. |
Brian Silverman | 6da0427 | 2014-05-18 18:47:48 -0700 | [diff] [blame] | 31 | |
Brian Silverman | 14fd0fb | 2014-01-14 21:42:01 -0800 | [diff] [blame] | 32 | The C++ namespace aos is used for all of the aos code. The crio and linux_code namespaces are for APIs that only make sense on one platform or the other. |
Brian Silverman | 6da0427 | 2014-05-18 18:47:48 -0700 | [diff] [blame] | 33 | |
| 34 | Almost everything in aos/ is thread-safe. Files with a main() might not be, and some pieces of code explicitly say at their declaration that they aren't. Also, code which shares non-const pointers (including this) is not generally thread-safe. Other than those exceptions, everything is assumed to be thread-safe so the comments don't say so explicitly. |