New BSP source structure
gedare at rtems.org
Tue Jan 30 14:16:26 UTC 2018
On Tue, Jan 30, 2018 at 1:44 AM, Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
> On 29/01/18 21:45, Chris Johns wrote:
>> On 29/1/18 6:32 pm, Sebastian Huber wrote:
>>> 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
>>> 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
>>> ** 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
>>> only one file.
>> I am the same. The directories can be simplified.
> 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.huber at embedded-brains.de
> PGP : Public key available on request.
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> devel mailing list
> devel at rtems.org
More information about the devel