Unused stm32f4x and stm32f7x files

[Chris Johns]

On 23/04/2018 01:25, Sebastian Huber wrote:
> 
> Yes, but both sets are unused. Would you
> 
> 1. remove these unused sources
> 2. move them to bsps/arm
> 
> ?

It raises a similar question I considered with the removal of the unused gdb
stub file in the previous round of changes. The answer I came to was ...

A BSP may not reference the code but it may be referenced by application code
running on the BSP. The code may have been provided in the BSP as a service to
the users of the BSP. I do this with debugging support where applications are
given the ability to optionally enabled debugging support based on a site
specific configuration or option.

Should we allow unreferenced code to exist in the source tree when we cannot run
or test it or should we require the code be referenced so it can be linked and
tested?

This statement as a requirement to require linking and tests exposes a conflict.
How do we test BSP specific features and how do developers with no hardware test
these features? I decided we cannot so we may have code in BSPs we do not link
or test so making a fixed and narrow requirement is not possible. We should
however do all we can to have coverage.

In the end I concluded we need to review on a case by case basis to decide. In
the case of the gdb stub removal it was OK because we now have libdebugger to
fill that role and there are some tests for that code. It may not support a
serial stub at the moment but it can be added. Vendor hardware libraries can be
merged into an application at the user site level or a 3rd party library can be
added to the RSB.

I am OK with this code being removed.

Chris