BSP names

[Joel Sherrill]

On Fri, Jul 19, 2019 at 4:33 AM Sebastian Huber <
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. :)

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.

FWIW when I explain BSPs and variants to people (like I did yesterday), I
try to get them to see that a specific BSP variant has an architecture, BSP
family,. BSP variant, and CPU model associated with it. But specific cases
like the erc32 and leon3 are confusing because the CPU model, BSP variant,
and CPU model are the same.

Anyway requirements are formal. Thus we should use the formal names.

--joel



>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax     : +49 89 189 47 41-09
> E-Mail  : sebastian.huber at embedded-brains.de
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20190719/c8127fa3/attachment-0002.html>