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>").
Ideally we would never have a family and BSP variant have the same name.
But that rule is violated multiple times now.
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>.
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.
--joel
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax: +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
> _______________________________________________
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
