<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jul 19, 2019 at 4:33 AM Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
I worked a bit with Doorstop and found the YAML file quite interesting. <br>
The file format is not without problems:<br>
<br>
<a href="https://arp242.net/yaml-config.html" rel="noreferrer" target="_blank">https://arp242.net/yaml-config.html</a><br>
<br>
However, for simple configuration stuff it is easy to write, read and <br>
process. Changes can be reviewed well in Git (content is spread over lines).<br>
<br>
I experiment currently a bit with using a YAML file to define the RTEMS <br>
build.<br>
<br>
How should BSPs be identified in the future? Should a BSP name be unique <br>
across architectures or do we want to use an "arch/bsp" tuple?<br></blockquote><div><br></div><div>Yes. :)</div><div><br></div><div>Seriously, I have been working on BSPs for running paravirtualized in Deos</div><div>(<a href="https://www.ddci.com/products_deos_do_178c_arinc_653/">https://www.ddci.com/products_deos_do_178c_arinc_653/</a>) on the arm, </div><div>powerpc, and i386. I started out with each architecture calling the bsp deos.</div><div>This worked for a while but eventually a change to the build system broke it.</div><div>Chris and I had a private (voice) discussion about this. <br></div><div><br></div><div>Historically, there never was a rule about this but I was the first case of using</div><div>the same BSP name across architectures. This probably should have happened</div><div>before for BSPs for gdb simulators but it just hadn't. We ended up with the rule</div><div>that BSP names should be unique across all architectures.</div><div><br></div><div>But I think formally, arch/bsp is a better way to do it. Besides being precise,</div><div>it implicitly encourages organizing BSPs by architecture.</div><div><br></div><div>FWIW when I explain BSPs and variants to people (like I did yesterday), I</div><div>try to get them to see that a specific BSP variant has an architecture, BSP</div><div>family,. BSP variant, and CPU model associated with it. But specific cases</div><div>like the erc32 and leon3 are confusing because the CPU model, BSP variant,</div><div>and CPU model are the same. </div><div><br></div><div>Anyway requirements are formal. Thus we should use the formal names.</div><div><br></div><div>--joel</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
-- <br>
Sebastian Huber, embedded brains GmbH<br>
<br>
Address : Dornierstr. 4, D-82178 Puchheim, Germany<br>
Phone   : +49 89 189 47 41-16<br>
Fax     : +49 89 189 47 41-09<br>
E-Mail  : <a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a><br>
PGP     : Public key available on request.<br>
<br>
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a></blockquote></div></div>