On 31/01/2018 01:16, Gedare Bloom wrote: > On Tue, Jan 30, 2018 at 1:44 AM, Sebastian Huber > <sebastian.hu...@embedded-brains.de> wrote: >> On 29/01/18 21:45, Chris Johns wrote: >>> >>> On 29/1/18 6:32 pm, Sebastian Huber wrote: >>>> >>>> Hello, >>>> >>>> now that all BSP header files are in >>>> >>>> * bsps/include >>>> >>>> * bsps/@RTEMS_CPU@/include >>>> >>>> * bsps/@RTEMS_CPU@/@RTEMS_BSP_FAMILY@/include >>>> >>>> we should also move the BSP sources to this new directory tree. How do we >>>> want >>>> to organize the BSP sources in bsps/@RTEMS_CPU@/@RTEMS_BSP_FAMILY@? >>>> >>> Yes this is a good thing to do. >> >> >> The question is this: should it go into the 5.1 release? I guess it needs >> three to six months to get this done. >> > I think our guiding philosophy moving forward is to cut a release with > any major change? We should not hold up a release for a second major > change like this, even if it is related. >
Backporting fixes going to be OK? >>> >>>> * include >>>> >>>> * start (Everything required to run a minimal application without >>>> devices) >>>> ** start.S >>>> ** bspstart.c >>>> ** linkcmds >>>> ** cache.c >>>> ** bspsmp.c >>>> >>>> * dev (Everything device driver related) >>>> ** clock.c >>>> ** console.c >>>> ** i2c.c >>>> ** spi.c >>>> >>>> * make >>>> ** somebsp.cfg >>>> >>>> * network (Legacy network stack drivers) > What about putting this under dev/net? > >>>> >>>> * mpci (RTEMS_MULTIPROCESSING support) >>>> >>> What about vendor sources for drivers? >> > As with 3rd party doc, I would suggest a contrib subdirectory of the > bsp for vendor sources and other imported code that is not directly > translated into a "standard" BSP file. +1 on using 'contrib' as the top level directory and the vendor's structure under that. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
