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