[6-freebsd-12 PATCH 1/2] rtemsbsd/bus: Add PCI support to the nexus bus

[Chris Johns]

On 3/3/21 7:48 pm, Sebastian Huber wrote:
> On 03/03/2021 08:52, Chris Johns wrote:
>> Then I hit minimum and some validation tests and they failed because I had
>> removed bsp/default-initial-extension.h and I suppose it needs to come via bsp.h
>> however it includes rtems.h because it needs to have access to
>> rtems_fatal_source etc.
>>
>> It seems there is a lot of places that subtly depend on bsp.h and what it
>> includes.
>>
>> I will chat to Joel tomorrow to figure out how this is to be resolved.
>>
>> Any suggestions?
> 
> The minimum requirement for bsp.h is to include:
> 
> rtems.h
> 
> bspopts.h

It is news to me this is a requirement and I am unsure where it has come from.
Has it been documented? The information you cut from my last post shows RTEMS is
pretty clean and the number of issues are small so I am not sure this needs to
happen.

These powerpc BSPs predate libbsd, they have legacy networking support and are
important to RTEMS users.

Your request to not including bsp.h because it includes rtems.h in a driver
section of a third party package that needs specific BSP bus mapping information
appear to conflict. The package needs low level BSP information but it cannot
include bsp.h by definition now.

What is now bugging me is the layering of rule upon rule mixed with defaults.
The rules are complex and in places seem arbitrary. Let me write the rules out
as I understand them:

1. The BSP header bsp.h is the access to BSP interfaces

2. The BSP header bsp.h must include rtems.h and bspopt.h

3. LibBSD generic bus handling must be inline for performance reasons

4. LibBSD generic bus handling assumes cache coherent memory by default

5. BSPs must register cache coherent memory if it does not meet rule 4

6. LibBSD generic bus handling defaults to a flat 1:1 full memory space
   address map

7. LibBSD generic bus handling requires bsp/bus.h to provide BSP mappings
   if it does not meet rule 6

8. A BSP provided bsp/bus.h cannot include rtems.h or any header that
   includes rtems.h such as bsp.h. This special case is exempt from rule 1

9. RTEMS cannot change any header an existing BSP with bsp/bus.h
   includes to include rtems.h or any header that has a dependent that
   includes rtems.h

<bleach> that is a lot of rules to swallow. An alternative set of rules is:

1. The BSP header bsp.h is the access to BSP interfaces

2. LibBSD generic bus handling must be inline for performance reasons

3. LibBSD generic bus handling requires a BSP provide suitable cache
   coherent memory to the cache coherent memory allocator

4. LibBSD generic bus handling requires a BSP provide bsp/bus.h to
   provide BSP IO mappings

The second set of rules is clear, does not self reference and universally
applies to all BSPs. It removes the defaults from LibBSD and lets us manage them
in rtems.git for a BSP. Explicitly requiring a BSP to provide support lets a
user easily check any BSP to see what cache coherent memory is configured and
what the bus handlers are.

> It shall also define BSP_INITIAL_EXTENSION (normally via #include
> <bsp/default-initial-extension.h>).

This is a recent addition and it is the only piece I found that has an issue
when building the motorola_powerpc. Maybe the way this is implemented is needs
to be reconsidered or we accept bsp.h does include rtems.h either directly or
indirectly.

The ability to interchange either bsp.h or rtems.h or having code that depends
on one because you include the other seems wrong.

Chris