chrisj at rtems.org
Sun Jul 21 02:08:44 UTC 2019
On 19/7/19 11:41 pm, Joel Sherrill wrote:
> On Fri, Jul 19, 2019 at 4:33 AM Sebastian Huber
> <sebastian.huber at embedded-brains.de <mailto:sebastian.huber at embedded-brains.de>>
> I worked a bit with Doorstop and found the YAML file quite interesting.
> The file format is not without problems:
> However, for simple configuration stuff it is easy to write, read and
> process. Changes can be reviewed well in Git (content is spread over lines).
> I experiment currently a bit with using a YAML file to define the RTEMS
> How should BSPs be identified in the future? Should a BSP name be unique
> across architectures or do we want to use an "arch/bsp" tuple?
> Yes. :)
Yes and +1.
This is the format I have standardised on for everything but building RTEMS, ie
rtems_waf which means libbsd. The kernel has the --target triplet and the bsp.
> Seriously, I have been working on BSPs for running paravirtualized in Deos
> (https://www.ddci.com/products_deos_do_178c_arinc_653/) on the arm,
> powerpc, and i386. I started out with each architecture calling the bsp deos.
> This worked for a while but eventually a change to the build system broke it.
> Chris and I had a private (voice) discussion about this.
> Historically, there never was a rule about this but I was the first case of using
> the same BSP name across architectures. This probably should have happened
> before for BSPs for gdb simulators but it just hadn't. We ended up with the rule
> that BSP names should be unique across all architectures.
> But I think formally, arch/bsp is a better way to do it. Besides being precise,
> it implicitly encourages organizing BSPs by architecture.
More information about the devel