BSP names

[Chris Johns]

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.

> 
> Seriously, I have been working on BSPs for running paravirtualized in Deos
> (https://www.ddci.com/products_deos_do_178c_arinc_653/) on the arm, 
> powerpc, and i386. I started out with each architecture calling the bsp deos.
> This worked for a while but eventually a change to the build system broke it.
> Chris and I had a private (voice) discussion about this. 
> 
> Historically, there never was a rule about this but I was the first case of using
> the same BSP name across architectures. This probably should have happened
> before for BSPs for gdb simulators but it just hadn't. We ended up with the rule
> that BSP names should be unique across all architectures.
> 
> But I think formally, arch/bsp is a better way to do it. Besides being precise,
> it implicitly encourages organizing BSPs by architecture.

Agreed.

Chris