New BSP source structure

[Chris Johns]

On 31/01/2018 01:16, Gedare Bloom wrote:
> 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:
>>>>
>>>> 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