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.
-- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
