BSP Console support (was Re: [PATCH] arm: mx6ulevk: Initial BSP support for i.MX 6UltraLite EVK board.)

[Chris Johns]

On 19/04/2016 19:31, Sebastian Huber wrote:
> Please don't use this console driver framework. Use
> rtems_termios_device_handler instead.

I am not on board with saying we do this and I have a few reasons which 
I would like to present and discuss.

The console support in BSPs is a mess and in general we have no standard 
rules so any debate on this topic is destined to be related to style, 
preference and history. We need to sort through these things and get a 
clear understand of the path we want to take and then support it.

To guide us I would like to propose some simple rules and while they 
specifically address consoles it does relate more broadly to all parts 
of a BSP.

1. One method to support consoles in a BSP.

Currently I think we have 4 or more ways console IO happens. There are 
direct low level writes to devices, simulator type writes, and termios, 
and within termios we have a couple of possible paths we can take. Joel, 
is this correct?

We should aim at a single termios solution as preferred. I am not sure 
if this is possible on low memory foot print targets and if it is not 
possible we should address that in a supported way.

2. Technical merit.

We should base the adoption of a solution on technical merit. This 
however needs to be in the context of documentation and migration.

3. Documentation.

For any solution to be accepted there needs to be documentation. 
Existing documentation should be given precedence over any technical merit.

4. Migration of existing BSPs.

There needs to be a defined and clear migration path. Without such a 
path the RTEMS Project ends up having to support all implementations for 
ever. Without a migration plan precedence has to be given to the 
solution that covers the most number of BSPs.

It would be nice to know where we stand with numbers?

5. Tier Status

  [ Tier documentation is coming ]

Any BPS that does not support the preferred console framework cannot be 
tier 1. If an architecture does not have a tier 1 BSP it cannot be a 
tier 1 architecture.

In relation to 'rtems_termios_device_handler' termios framework:

a) What is the technical reasons we adopt this framework?

b) Is the framework documented anywhere?

  ruru rtems.git $ grep -r rtems_termios_device_handler doc/
  ruru rtems.git $

while:

  ruru rtems.git $ grep -r rtems_termios_handler doc/
  doc/bsp_howto/console.t:const rtems_termios_handler 
my_driver_handler_polled = @{
  doc/bsp_howto/console.t:const rtems_termios_handler 
my_driver_handler_interrupt = @{
  doc/bsp_howto/console.t:extern const rtems_termios_handler 
my_driver_handler_polled;
  doc/bsp_howto/console.t:extern const rtems_termios_handler 
my_driver_handler_interrupt;
  doc/bsp_howto/console.t:  const rtems_termios_handler *handler = 
&my_driver_handler_interrupt;
  doc/bsp_howto/console.t:  const rtems_termios_handler *handler = 
&my_driver_handler_polled;
  ruru rtems.git $

c) What is the migration plan?

The PC BSP uses ns16550.c and not ns16550-context.c. This second file is 
almost a copy of the first. If I find a bug in either file should I 
attempt to fix both or ignore the one I cannot test?

If the new 'rtems_termios_device_handler' is adopted the PC BSP may 
loose its tier 1 status. In the future we should avoid doing this and a 
migration plan should address tier 1 BSPs first.

The copied driver change is unfortunate and highlights a concern I have. 
A change like this may allow a technically better solution to be 
delivered however it does not account for the time and effort others 
need to spend to migrate other BSPs. Once a change like this is accepted 
into the project the project becomes responsible for updating any 
dependent BSPs. History shows this does not happen and that is 
understandable, the RTEMS Project has no direct funding to do this work 
and expecting this to be done unfunded is not reasonable. Asking for a 
migration plan is a way the project can understand what else is required 
and how what will be done.

As I stated at the start of this post, I am not yet on board and I would 
like to understand how we address the situation we are now in. Without a 
clear understand of this any new BSP is at risk.

Chris