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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
