[PATCH v2 2/6] cpukit: Add Exception Manager

[Kinsey Moore]

On 10/1/2021 08:29, Sebastian Huber wrote:
> On 01/10/2021 06:39, Gedare Bloom wrote:
>> You also might separate the exception manager addition away from the
>> topic of recoverable exceptions. This introduces/extends the classic
>> API, so it needs to be vetted carefully. Although the new header
>> claims to be a classic API, it appears to not follow classic API
>> conventions. You might need to think about what needs to be exposed to
>> the application level, and how, versus what should be internal. And
>> follow the conventions for classic API usage (e.g., opaque types not
>> pointers).
>
> Yes, the <rtems/*.h> is reserved for API header files. The 
> architecture-independent implementation part (Exception Handler) 
> should go to <rtems/score/*.h>. The architecture-dependent part should 
> go in <rtems/score/cpuimpl.h>.  If something really (!) needs to be 
> visible to the API, then it should go in <rtems/score/cpu.h>. The 
> architecture-dependent parts should be documented in the no_cpu header 
> files.
>
> Please make the architecture-dependent interface more abstract. From 
> my point of view your current approach contains to many details of the 
> aarch64 port.
>
> There should be documentation in the RTEMS CPU Supplement with a 
> status for each architecture (similar to the TLS support).
>
> At the moment I only see one API element and this is the new 
> application configuration option.
>
> If you really need new rtems_* interfaces, then please add a proper 
> documentation for them so that it could be included in the RTEMS 
> Classic API Guide. I would prefer to wait with new API elements until 
> at this is implemented on at least another architecture.
>
Thanks for the feedback, Gedare and Sebastian. I'll get this refactored 
as suggested and keep everything but the configuration option out of the 
API.


Sebastian,

Could you be more specific about which parts of the 
architecture-dependent interface still seem tied to the AArch64 port? I 
thought I had made them sufficiently abstract by relying on 
architecture-specific functions to manipulate and take action on the 
exception frame. The signal mapping code written on top of this should 
work for any architecture that implements those functions and contains 
no reliance on architecture that I can see. The set of exception classes 
in particular includes exceptions that don't exist on AArch64, but were 
added because they're known to be present on SPARC and need to be 
handled. I'm only really familiar with ARM and AArch64, so that could be 
why I'm missing it.


Kinsey