On 22/7/21 8:35 am, Joel Sherrill wrote:
> On Wed, Jul 21, 2021 at 2:10 PM Sebastian Huber
> <sebastian.hu...@embedded-brains.de> wrote:
>>
>> On 21/07/2021 21:05, Gedare Bloom wrote:
>>>>> The problem is that one BSP which supports SMP "riscv/griscv" is
>>>>> identical to
>>>>> the family "riscv/griscv" which contains BSPs which do not support SMP
>>>>> ("riscv/grv32i" and riscv/grv32im").
>>>> Hmm, tricky. Can the BSPs that do not support SMP disable SMP in the BSP
>>>> specific config, ie override/specialise in the BSP?
>>>>
>>> Or, can we avoid having duplication between BSP names and family names?
>>
>> Yes, good idea. We could use a "family/" prefix for example
>> ("family/<arch>/<bsp-family-name>").
Great idea.
> Ideally we would never have a family and BSP variant have the same name.
> But that rule is violated multiple times now.
Yeap.
> I am not sure where your triple is intended to be used but we have used
> the pattern arch/BSP which is really <arch>/<bsp_variant> as the
> full name of BSPs.
>
> If we want to step that further, we could do something similar to the
> GNU target triple where the middle component is a rarely used vendor.
> <arch>/<bsp_family>/<bsp_variant>.
I think we are to late for this because the spec file format follows what I did
in the eco-system and I would prefer we maintained a single unified way of doing
this than changing it.
> In recent history, there was an issue of BSP variant names needing to
> be unique across all architectures. This may also need to apply to bsp
> family names.
What about "bsps/<family>". This means you have:
powerpc/mvme2307
bsps/motorola_powerpc
It is simple and clean.
Chris
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
