Re: New API directives to enable/disable interrupt vectors
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
Re: New API directives to enable/disable interrupt vectors
On 18/6/21 1:28 am, Gedare Bloom wrote:
> On Wed, Jun 16, 2021 at 11:40 PM Sebastian Huber
> wrote:
>>
>> On 16/06/2021 20:36, Gedare Bloom wrote:
>>> Looks like the existing irq-extension.h uses 'vector', so
>>> rtems_interrupt_disable_vector() is a possibility, or else
>>> rtems_interrupt_controller_disable_vector() is more wordy but if we
>>> want to treat 'interrupt controller' as its own category of API
>>> separate from 'interrupt'.
>>
>> Yes, mixing "vector" into the name a good idea. What about
>> rtems_interrupt_vector_enable() and rtems_interrupt_vector_disable()?
>>
>> I am not that fond of using "interrupt controller" since I don't want to
>> change the existing API and it would result in very long directive names.
>>
> I'm fine with the rtems_interrupt_vector_* to distinguish between the
> score/cpu level support, and the bsp/irq controllers. We already use
> this for example as "bsp_interrupt_vector_enable()". I think it will
> be great to lift this "bsp" interface up to the "rtems" level.
I have no objection to any of this but it raised my interest in what is the
whole rtems_interrupt_* API and how consistent it is ...
I have managed to filter the cpukit headers [1] to get:
rtems_interrupt_catch
rtems_interrupt_cause
rtems_interrupt_clear
rtems_interrupt_disable
rtems_interrupt_enable
rtems_interrupt_flash
rtems_interrupt_is_in_progress
rtems_interrupt_level_body
rtems_interrupt_local_disable
rtems_interrupt_local_enable
rtems_interrupt_handler_install
rtems_interrupt_handler_iterate
rtems_interrupt_handler_remove
rtems_interrupt_get_affinity
rtems_interrupt_set_affinity
rtems_interrupt_lock_acquire
rtems_interrupt_lock_acquire_isr
rtems_interrupt_lock_destroy
rtems_interrupt_lock_initialize
rtems_interrupt_lock_interrupt_disable
rtems_interrupt_lock_release
rtems_interrupt_lock_release_isr
rtems_interrupt_server_action_prepend
rtems_interrupt_server_create
rtems_interrupt_server_delete
rtems_interrupt_server_entry_destroy
rtems_interrupt_server_entry_initialize
rtems_interrupt_server_entry_move
rtems_interrupt_server_entry_submit
rtems_interrupt_server_handler_install
rtems_interrupt_server_handler_iterate
rtems_interrupt_server_handler_remove
rtems_interrupt_server_initialize
rtems_interrupt_server_move
rtems_interrupt_server_request_destroy
rtems_interrupt_server_request_initialize
rtems_interrupt_server_request_set_vector
rtems_interrupt_server_request_submit
rtems_interrupt_server_resume
rtems_interrupt_server_set_affinity
rtems_interrupt_server_suspend
The list does not capture things like rtems_interrupt_mask which is a typedef.
My concern is:
rtems_interrupt_disable
rtems_interrupt_enable
rtems_interrupt_local_disable
rtems_interrupt_local_enable
and then we add:
rtems_interrupt_vector_disable
rtems_interrupt_vector_enable
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 am not across enough of the detail to comment specifically about this and I am
happy to see what others think and follow their lead.
Chris
[1] egrep -r 'rtems_interrupt_.*\(' cpukit/include | sed -e 's/.*
\(rtems_interrupt_.*\).*/\1/' | sed -e 's/(.*//' | grep '^rtems' | sort | uniq
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: New API directives to enable/disable interrupt vectors
On Wed, Jun 16, 2021 at 11:40 PM Sebastian Huber wrote: > > On 16/06/2021 20:36, Gedare Bloom wrote: > > Looks like the existing irq-extension.h uses 'vector', so > > rtems_interrupt_disable_vector() is a possibility, or else > > rtems_interrupt_controller_disable_vector() is more wordy but if we > > want to treat 'interrupt controller' as its own category of API > > separate from 'interrupt'. > > Yes, mixing "vector" into the name a good idea. What about > rtems_interrupt_vector_enable() and rtems_interrupt_vector_disable()? > > I am not that fond of using "interrupt controller" since I don't want to > change the existing API and it would result in very long directive names. > I'm fine with the rtems_interrupt_vector_* to distinguish between the score/cpu level support, and the bsp/irq controllers. We already use this for example as "bsp_interrupt_vector_enable()". I think it will be great to lift this "bsp" interface up to the "rtems" level. > -- > 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
Re: New API directives to enable/disable interrupt vectors
On Thu, Jun 17, 2021 at 12:40 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 16/06/2021 20:36, Gedare Bloom wrote: > > Looks like the existing irq-extension.h uses 'vector', so > > rtems_interrupt_disable_vector() is a possibility, or else > > rtems_interrupt_controller_disable_vector() is more wordy but if we > > want to treat 'interrupt controller' as its own category of API > > separate from 'interrupt'. > > Yes, mixing "vector" into the name a good idea. What about > rtems_interrupt_vector_enable() and rtems_interrupt_vector_disable()? > I like this. Interrupt vector refers to the source not the hardware being manipulated. > > I am not that fond of using "interrupt controller" since I don't want to > change the existing API and it would result in very long directive names. > I know they are usually called interrupt controllers but you are right, it is longer and implies a technology. --joel > > -- > 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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: New API directives to enable/disable interrupt vectors
On 16/06/2021 20:36, Gedare Bloom wrote: Looks like the existing irq-extension.h uses 'vector', so rtems_interrupt_disable_vector() is a possibility, or else rtems_interrupt_controller_disable_vector() is more wordy but if we want to treat 'interrupt controller' as its own category of API separate from 'interrupt'. Yes, mixing "vector" into the name a good idea. What about rtems_interrupt_vector_enable() and rtems_interrupt_vector_disable()? I am not that fond of using "interrupt controller" since I don't want to change the existing API and it would result in very long directive names. -- 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
Re: New API directives to enable/disable interrupt vectors
On Wed, Jun 16, 2021 at 12:34 PM Gedare Bloom wrote: > > On Wed, Jun 16, 2021 at 5:23 AM Sebastian Huber > wrote: > > > > Hello, > > > > I work currently on an extension of the interrupt manager API: > > > > https://devel.rtems.org/ticket/3269 > > > > This API is not related to the interrupt handling at processor level. It > > is related to the management of interrupts at the interrupt controller > > level. > > > What happens in case there's no controller? > > > We need directives to enable and disable interrupt vectors. > > Unfortunately, rtems_interrupt_enable() and rtems_interrupt_disable() > > are already occupied. My first approach was to use > > rtems_interrupt_mask() and rtems_interrupt_unmask(), however, I noticed > > that rtems_interrupt_mask is already used. What about > > > > rtems_interrupt_permit() > > > > and > > > > rtems_interrupt_forbid() > > > > ? > > > Implicitly, rtems_interrupt_* means a directive oriented toward the > CPU side of the interrupt management? It seems there should be an > explicit indicator of API calls that target the controller side, like > rtems_interrupt_controller_xxx()? > > Then you can reuse directive names, like > rtems_interrupt_controller_disable(). Unless there's a possibility to > enable/disable the controller itself. in which case, we'd need > something else like rtems_interrupt_controller_disable_irq(int irq) or > whatever, and perhaps rtems_interrupt_controller_disable_irqs(). > Looks like the existing irq-extension.h uses 'vector', so rtems_interrupt_disable_vector() is a possibility, or else rtems_interrupt_controller_disable_vector() is more wordy but if we want to treat 'interrupt controller' as its own category of API separate from 'interrupt'. > > -- > > 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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: New API directives to enable/disable interrupt vectors
On Wed, Jun 16, 2021 at 5:23 AM Sebastian Huber wrote: > > Hello, > > I work currently on an extension of the interrupt manager API: > > https://devel.rtems.org/ticket/3269 > > This API is not related to the interrupt handling at processor level. It > is related to the management of interrupts at the interrupt controller > level. > What happens in case there's no controller? > We need directives to enable and disable interrupt vectors. > Unfortunately, rtems_interrupt_enable() and rtems_interrupt_disable() > are already occupied. My first approach was to use > rtems_interrupt_mask() and rtems_interrupt_unmask(), however, I noticed > that rtems_interrupt_mask is already used. What about > > rtems_interrupt_permit() > > and > > rtems_interrupt_forbid() > > ? > Implicitly, rtems_interrupt_* means a directive oriented toward the CPU side of the interrupt management? It seems there should be an explicit indicator of API calls that target the controller side, like rtems_interrupt_controller_xxx()? Then you can reuse directive names, like rtems_interrupt_controller_disable(). Unless there's a possibility to enable/disable the controller itself. in which case, we'd need something else like rtems_interrupt_controller_disable_irq(int irq) or whatever, and perhaps rtems_interrupt_controller_disable_irqs(). > -- > 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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
New API directives to enable/disable interrupt vectors
Hello, I work currently on an extension of the interrupt manager API: https://devel.rtems.org/ticket/3269 This API is not related to the interrupt handling at processor level. It is related to the management of interrupts at the interrupt controller level. We need directives to enable and disable interrupt vectors. Unfortunately, rtems_interrupt_enable() and rtems_interrupt_disable() are already occupied. My first approach was to use rtems_interrupt_mask() and rtems_interrupt_unmask(), however, I noticed that rtems_interrupt_mask is already used. What about rtems_interrupt_permit() and rtems_interrupt_forbid() ? -- 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
