BSPs with Same Name, Different Architecture

[Gedare Bloom]

On Wed, May 16, 2018 at 9:41 AM, Joel Sherrill <joel at rtems.org> wrote:
>
>
> On Wed, May 16, 2018 at 6:32 AM, Joel Sherrill <joel at rtems.org> wrote:
>>
>>
>>
>> On Wed, May 16, 2018, 4:05 AM Chris Johns <chrisj at rtems.org> wrote:
>>>
>>> On 15/5/18 3:39 am, Joel Sherrill wrote:
>>> > On Mon, May 14, 2018, 10:16 AM Gedare Bloom <gedare at rtems.org
>>> > <mailto:gedare at rtems.org>> wrote:
>>> >
>>> >     This is an excellent rule. BSP names should be unique.
>>> >
>>> > I am not sure the current logic ensures that but it did break one of my
>>> > name reuses.
>>>
>>> I did not intend to change this.
>>
>>
>> I didn't think you did but it is an ok rule.
>
>
> Adding to that simple response.
>
> Historically, this rule was implicitly in place for the entire period that
> the .cfg
> files were in make/custom at the top of the tree. It was only when they
> moved
> under libbsp/ and now bsps/, that this is even a possibility. I suppose the
> BSP family directories would have been ok to duplicate.
>
> During the period while it was possible for two BSP variants to have the
> same
> name, the .cfg files still installed into ${prefix}/make/custom. So the last
> BSP
> installed won. I think duplicate BSP family names would have worked.
>
> In the long history of RTEMS, I think I am the only person who managed to
> name BSPs in different architectures the same. I suppose it would be
> tempting
> to do the same with gdb or qemu BSPs, but qemu has so many variants that
> it wouldn't make sense there. I named the BSP families and variants "deos"
> since the paravirtualized RTEMS is hosted on Deos.
>
> The test for valid BSP is based on wildcard'ing for linkcmds. If BSP
> families
> have the same name in multiple architectures, it will find an arbitrary one.
> That's what tripped me up.
>
> We need to have a rule for BSP family directories and BSP variants. At this
> point, I have unique BSP variants (e.g. deos_x86, deos_ppc, etc) and the
> BSP family name is deos on all three architectures. This does work.
>
> I am OK with whatever decision we make. We just need to be conscious
> of it, document it somewhere (Coding Conventions, BSP Guide) and note
> where it needs to be enforced in the build system.
>

BSP guide should be sufficient user docu.

> --joel
>
> --joel
>
>
>
>
>>>
>>>
>>> Chris
>
>