BSP names

[Chris Johns]

On 23/7/19 5:36 pm, Sebastian Huber wrote:
> On 21/07/2019 04:08, Chris Johns wrote:
>> On 19/7/19 11:41 pm, Joel Sherrill wrote:
>>> On Fri, Jul 19, 2019 at 4:33 AM Sebastian Huber
>>> <sebastian.huber at embedded-brains.de 
>>> <mailto:sebastian.huber at embedded-brains.de>>
>>> wrote:
>>>
>>>      Hello,
>>>
>>>      I worked a bit with Doorstop and found the YAML file quite interesting.
>>>      The file format is not without problems:
>>>
>>>      https://arp242.net/yaml-config.html
>>>
>>>      However, for simple configuration stuff it is easy to write, read and
>>>      process. Changes can be reviewed well in Git (content is spread over
>>> lines).
>>>
>>>      I experiment currently a bit with using a YAML file to define the RTEMS
>>>      build.
>>>
>>>      How should BSPs be identified in the future? Should a BSP name be unique
>>>      across architectures or do we want to use an "arch/bsp" tuple?
>>>
>>>
>>> Yes.:)
>> Yes and +1.
>>
>> This is the format I have standardised on for everything but building RTEMS, ie
>> rtems_waf which means libbsd. The kernel has the --target triplet and the bsp.
> 
> Ok, good.
> 
> Some background information about what I am experimenting. To make the ECSS
> standard happy, we have to deliver a Software Configuration File (SCF) for
> example. This overlaps a bit with the information necessary to build RTEMS. I
> would like to concentrate the information in Doorstop maintained files and
> generate different outputs based on the intended usage, e.g. an SCF or build
> files (Makefile, waf). Another example is that we may have a requirement like
> this: The compiler flags for the XYZ BSP shall be "-O2 -g -mleon3". We could add
> the compiler flags to a BSP-specific configuration item which has a "cflags: -O2
> -g -mleon3" attribute. We can use this attribute to generate a human readable
> requirement in an Software Requirements Specification (SRS) and the build file.
> The compiler flags just have one master data, everything else is derived and
> produced by tools.
> 

Also remember you have DWARF and with that you can see all the flags used,
actually you can see lots of things. The executable information command provides
you with all the machine flags used in all object files in an executable, ie the
final output ...

https://docs.rtems.org/branches/master/user/tools/exeinfo.html

This becomes useful when you step away from compiler flags to requirements about
the pieces that can used and linked in and with the awesome linker set support
we have things that can go unnoticed.

The rtems-exeinfo is there as a base framework to provide any auditing tools
when you need to know if requirements are been met. A DWARF audit extends across
all parts of the process from the building of the tools, RTEMS, 3rd party
libraries to applications without needing to be concerned about the whys or wheres.

The approach provides the flexibility of avoid stripped down libraries and the
impact that could cause on the RTEMS project because you can post process a link
and enforce any rules determined by the requirements. Testing at any layer in a
vertical stack can validate that stage.

Chris