[PATCH v2 2/6] cpukit: Add Exception Manager
Kinsey Moore
kinsey.moore at oarcorp.com
Fri Oct 1 19:39:59 UTC 2021
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
More information about the devel
mailing list