On 18/06/2021 03:30, Chris Johns wrote:
The list does not capture things like rtems_interrupt_mask which is a typedef.
The rtems_interrupt_mask is a constant object:
/**
* @ingroup RTEMSAPIClassicModes
*
* @brief This task mode constant has the same value as
#RTEMS_INTERRUPT_MASK.
*
* @par Notes
* This task mode constant is used by bindings from languages other
than C and
* C++.
*/
extern const uint32_t rtems_interrupt_mask;
My concern is:
rtems_interrupt_disable
rtems_interrupt_enable
The two macros above are a legacy interface available only in
uniprocessor configurations.
rtems_interrupt_local_disable
rtems_interrupt_local_enable
and then we add:
rtems_interrupt_vector_disable
rtems_interrupt_vector_enable
So basically we have to compare these two variants. I think the names
which include "local" and "vector" are clear enough from my point of
view. The primary use case for the vector enable/disable is probably
test code.
How do each of these enable/disable pairs interact with the other parts of the
API?
This also seems to pull back to Sebastian's initial comment about the
enable/disable being occupied and I wonder if that concern highlights the need
for some cleaning in the API? It is does it may take a release or 2 to migrate
users but it may be worth it in the long run if the API is made clearer.
I will send a patch set in the next days with a proposal for some new
directives. I would not change what we have.
--
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
