On 19/7/19 11:41 pm, Joel Sherrill wrote: > On Fri, Jul 19, 2019 at 4:33 AM Sebastian Huber > <sebastian.hu...@embedded-brains.de > <mailto:sebastian.hu...@embedded-brains.de>> > wrote: > > Hello, > > I worked a bit with Doorstop and found the YAML file quite interesting. > The file format is not without problems: > > https://arp242.net/yaml-config.html > > 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 > build. > > 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. Agreed. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
