BSPs with Same Name, Different Architecture

[Joel Sherrill]

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.

--joel

--joel





>
>> Chris
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180516/05f931e0/attachment-0002.html>