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.
>> >>> * 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. > > I think they should keep the original vendor layout as much as possible. > >> >>> I am not a big fan of the excessive use of subdirectories which contain >>> usually >>> only one file. >> >> I am the same. The directories can be simplified. >> >> Chris > > > -- > Sebastian Huber, embedded brains GmbH > > Address : Dornierstr. 4, D-82178 Puchheim, Germany > Phone : +49 89 189 47 41-16 > Fax : +49 89 189 47 41-09 > E-Mail : sebastian.hu...@embedded-brains.de > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
