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