I am a newbie to RTEMS, but this sounds great. The current layout is
very confusing to newcomers. Kudos to you, Amar!
Please, see my notes further on.
On 03/07/2015 02:20 AM, Amar Takhar wrote:
The following is a proposal for a new source layout that will be included in the
new 'waf' build system. The current layout is a product of years of laying and
requirements for the auto* build system. Since we are no longer restricted by
this it makes sense to take the time and give RTEMS a more sensible source
layout.
rtems/bsp/* exists to carry common bsp files. I don't know why it makes sense
to have score/* then cpu/* with separate architectures. Even if the purpose is
different does it make sense to have two completely separate areas with
architecture hierarchies? There may have been a reason to do this before is
there one now?
There are some interdependencies between the common BSP files (bsp.h). I can
hack around this for now using waf until we can break this interdependency by
moving to public APIs.
Note: the reason for rtems/bsp/* existing is to unhook rtems/ and bsp/ 100%.
This means you can develop a BSP with only librtems installed on your system and
nothing else. We will also support a build that does not build any BSP code.
It will also allow us to split our tests correctly as well.
I will propose a 1:1 mapping of all source and header files from current -> new
location for approval once we have the general layout completed. I would like
to avoid renaming the source files themselves until after we have moved and
verified everything builds OK. Renaming the files in-dir is a trivial
operation and can be verified using a hash of the resulting libraries.
include locations
~~~~~~~~~~~~~~~~~
include/rtems/include/ - Private API
include/rtems/include/rtems/ - Public API
include/rtems/bsp/include/ - Common BSP files
include/rtems/bsp/include/<arch> - Architecture specific
Just one question here: Why have the public API hidden in a subdir of
private APIs? Shouldn't this be the other way around?
rtems
~~~~
rtems/lib/ada/ [c/src/ada]
rtems/lib/block
rtems/lib/csupport
rtems/lib/fs
rtems/lib/misc
rtems/lib/networking
rtems/lib/rpc
rtems/lib/z
rtems/lib/qos
rtems/lib/md
rtems/lib/gnat
rtems/lib/i2c
rtems/lib/rtems++ [c/src/librtems++]
rtems/classic [cpukit/rtems]
Again, I'm a newbie, but what is 'classic' in RTEMS?
The old 'cpukit' sounds like it's a bunch of tools to work with the CPU.
The new 'classic' sounds like it's the good old RTEMS from history.
rtems/posix
rtems/sapi
rtems/server/ftpd
rtems/server/mghttpd
rtems/server/pppd
rtems/score
The following need to be discussed in detail as they will end up split into
multiple locations:
rtems/bsp/chip/ [c/src/libchip]
rtems/bsp/shared/<arch> [c/src/lib/libcpu]
Note: c/src/support has been killed.
bsp (contents of c/src/lib/libbsp, actual BSP source)
~~~
bsp/<arch>/
bsp/<arch>/<bsp>/
bsp/<arch>/<bsp>/include <-installable BSP headers.
installed locations
~~~~~~~~~~~~~~~~~~
include/rtems/ - Public API
include/rtems/bsp/ - Common BSP files
include/rtems/bsp/<arch>/ - Architecture specific
include/rtems/bsp/<arch/<bsp>/ - BSP specific
changes to source
~~~~~~~~~~~~~~~~
- All RTEMS source will use #include <rtems/header.h> for public API
You actually mean "<rtems/header.h>" and not "<rtems/rtems.h>" or even
just "<rtems.h>"? When you say "RTEMS source" and "public API", do you
mean the RTEMS source code or 3rd party source that builds with RTEMS?
Other than that, good job, Amar. :)
Dominik
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
