[Xenomai-core] [PATCH] Shared irqs v.5

[Xenomai-core] [PATCH] Shared irqs v.5

[Dmitry Adamushko]

[-- Attachment #1.1: Type: text/plain, Size: 263 bytes --]

Hello Jan,

as I promised earlier today, here is the patch.

hehe.. more comments later together with other explanations I promised. I
have to go now since I have to make a trip and my bus is leaving in 45
minutes :)

--
Best regards,
Dmitry Adamushko

[-- Attachment #1.2: Type: text/html, Size: 298 bytes --]

[-- Attachment #2: shirq-v4.patch --]
[-- Type: application/octet-stream, Size: 10469 bytes --]

diff -urp xenomai-cvs/include/asm-generic/hal.h xenomai/include/asm-generic/hal.h
--- xenomai-cvs/include/asm-generic/hal.h	2006-01-13 15:10:23.000000000 +0100
+++ xenomai/include/asm-generic/hal.h	2006-01-18 12:35:49.000000000 +0100
@@ -62,6 +62,7 @@
 #define RTHAL_NR_CPUS		IPIPE_NR_CPUS
 #define RTHAL_ROOT_PRIO		IPIPE_ROOT_PRIO
 #define RTHAL_NR_FAULTS		IPIPE_NR_FAULTS
+#define RTHAL_NR_IRQS		IPIPE_NR_IRQS
 
 #define RTHAL_SERVICE_IPI0	IPIPE_SERVICE_IPI0
 #define RTHAL_SERVICE_VECTOR0	IPIPE_SERVICE_VECTOR0
diff -urp xenomai-cvs/include/asm-generic/system.h xenomai/include/asm-generic/system.h
--- xenomai-cvs/include/asm-generic/system.h	2006-01-03 19:53:37.000000000 +0100
+++ xenomai/include/asm-generic/system.h	2006-01-18 12:13:03.000000000 +0100
@@ -470,6 +470,16 @@ static inline unsigned long long xnarch_
 
 #ifdef XENO_INTR_MODULE
 
+#define XNARCH_NR_IRQS		     RTHAL_NR_IRQS
+
+static inline unsigned long xnarch_critical_enter(void (*synch)(void)) {
+    return rthal_critical_enter(synch);
+}
+
+static inline void xnarch_critical_exit(unsigned long flags) {
+    return rthal_critical_exit(flags);
+}
+
 static inline int xnarch_hook_irq (unsigned irq,
 				   rthal_irq_handler_t handler,
 				   rthal_irq_ackfn_t ackfn,
diff -urp xenomai-cvs/include/asm-sim/system.h xenomai/include/asm-sim/system.h
--- xenomai-cvs/include/asm-sim/system.h	2006-01-03 19:53:37.000000000 +0100
+++ xenomai/include/asm-sim/system.h	2006-01-18 12:30:17.000000000 +0100
@@ -365,6 +365,16 @@ void mvm_tcl_build_pendq(mvm_tcl_listobj
 typedef void (*rthal_irq_handler_t)(unsigned, void *);
 typedef int (*rthal_irq_ackfn_t)(unsigned);
 
+#define XNARCH_NR_IRQS		     MVM_IRQ_LEVELS
+
+static inline unsigned long xnarch_critical_enter(void (*synch)(void)) {
+    return 0;
+}
+
+static inline void xnarch_critical_exit(unsigned long flags) {
+    return;
+}
+
 static inline int xnarch_hook_irq (unsigned irq,
 				   rthal_irq_handler_t handler,
 				   rthal_irq_ackfn_t ackfn, /* Ignored. */
diff -urp xenomai-cvs/include/asm-uvm/system.h xenomai/include/asm-uvm/system.h
--- xenomai-cvs/include/asm-uvm/system.h	2006-01-08 15:35:54.000000000 +0100
+++ xenomai/include/asm-uvm/system.h	2006-01-18 12:17:18.000000000 +0100
@@ -270,6 +270,16 @@ void xnarch_sync_irq (void) /* Synchroni
 typedef void (*rthal_irq_handler_t)(unsigned, void *);
 typedef int (*rthal_irq_ackfn_t)(unsigned);
 
+#define XNARCH_NR_IRQS		     0
+
+static inline unsigned long xnarch_critical_enter(void (*synch)(void)) {
+    return 0;
+}
+
+static inline void xnarch_critical_exit(unsigned long flags) {
+    return;
+}
+
 static inline int xnarch_hook_irq (unsigned irq,
 				   rthal_irq_handler_t handler,
 				   rthal_irq_ackfn_t ackfn,
diff -urp xenomai-cvs/include/nucleus/intr.h xenomai/include/nucleus/intr.h
--- xenomai-cvs/include/nucleus/intr.h	2005-11-01 23:37:45.000000000 +0100
+++ xenomai/include/nucleus/intr.h	2006-01-18 15:32:09.000000000 +0100
@@ -26,21 +26,31 @@
 #define XN_ISR_CHAINED   0x1
 #define XN_ISR_ENABLE    0x2
 
+/* Creation flags. */
+#define XN_ISR_SHARED	 0x1
+
+/* Operational flags. */
+#define XN_ISR_ATTACHED	 0x100
+
 #if defined(__KERNEL__) || defined(__XENO_UVM__) || defined(__XENO_SIM__)
 
 struct xnintr;
 
 typedef struct xnintr {
 
-    unsigned irq;	/* !< IRQ number. */
+    struct xnintr *next;
 
     xnisr_t isr;	/* !< Interrupt service routine. */
 
-    xniack_t iack;	/* !< Interrupt acknowledge routine. */
+    void *cookie;	/* !< User-defined cookie value. */
 
     unsigned long hits;	/* !< Number of receipts (since attachment). */
 
-    void *cookie;	/* !< User-defined cookie value. */
+    xnflags_t flags; 	/* !< Creation flags. */
+
+    unsigned irq;	/* !< IRQ number. */
+
+    xniack_t iack;	/* !< Interrupt acknowledge routine. */
 
 } xnintr_t;
 
@@ -50,6 +60,8 @@ extern xnintr_t nkclock;
 extern "C" {
 #endif
 
+int xnintr_mount(void);
+
 void xnintr_clock_handler(void);
 
     /* Public interface. */
Only in xenomai/include/nucleus: shirq-3_intr.h.patch
diff -urp xenomai-cvs/ksrc/nucleus/intr.c xenomai/ksrc/nucleus/intr.c
--- xenomai-cvs/ksrc/nucleus/intr.c	2005-12-02 19:56:20.000000000 +0100
+++ xenomai/ksrc/nucleus/intr.c	2006-01-18 15:32:56.000000000 +0100
@@ -41,6 +41,60 @@ xnintr_t nkclock;
 static void xnintr_irq_handler(unsigned irq,
 			       void *cookie);
 
+static void xnintr_shirq_handler(unsigned irq,
+			       void *cookie);
+
+typedef struct xnintr_shirq {
+
+    xnintr_t *handlers;
+    
+#ifdef CONFIG_SMP
+    atomic_counter_t active;
+#endif /* CONFIG_SMP */
+
+} xnintr_shirq_t;
+
+static xnintr_shirq_t xnshirqs[XNARCH_NR_IRQS];
+
+#ifdef CONFIG_SMP
+
+static inline void xnintr_shirq_lock(xnintr_shirq_t *shirq)
+{
+    xnarch_atomic_inc(&shirq->active);
+}
+
+static inline void xnintr_shirq_unlock(xnintr_shirq_t *shirq)
+{
+    xnarch_atomic_dec(&shirq->active);
+}
+
+static inline void xnintr_shirq_spin(xnintr_shirq_t *shirq)
+{
+    while (xnarch_atomic_get(&shirq->active))
+	cpu_relax();
+}
+
+#else /* !CONFIG_SMP */
+
+static inline void xnintr_shirq_lock(xnintr_shirq_t *shirq) {}
+static inline void xnintr_shirq_unlock(xnintr_shirq_t *shirq) {}
+static inline void xnintr_shirq_spin(xnintr_shirq_t *shirq) {}
+
+#endif /* CONFIG_SMP */
+
+int xnintr_mount(void)
+{
+    int i;
+    for (i = 0; i < XNARCH_NR_IRQS; ++i)
+	{
+	xnshirqs[i].handlers = NULL;
+#ifdef CONFIG_SMP
+	atomic_set(&xnshirqs[i].active,0);
+#endif /* CONFIG_SMP */
+	}
+    return 0;
+}
+
 /*! 
  * \fn int xnintr_init (xnintr_t *intr,unsigned irq,xnisr_t isr,xniack_t iack,xnflags_t flags)
  * \brief Initialize an interrupt object.
@@ -130,6 +184,8 @@ int xnintr_init (xnintr_t *intr,
     intr->iack = iack;
     intr->cookie = NULL;
     intr->hits = 0;
+    intr->flags = flags;
+    intr->next = NULL;
 
     return 0;
 }
@@ -164,7 +220,8 @@ int xnintr_init (xnintr_t *intr,
 int xnintr_destroy (xnintr_t *intr)
 
 {
-    return xnintr_detach(intr);
+    xnintr_detach(intr);
+    return 0;
 }
 
 /*! 
@@ -181,8 +238,7 @@ int xnintr_destroy (xnintr_t *intr)
  *
  * @param cookie A user-defined opaque value which is stored into the
  * interrupt object descriptor for further retrieval by the ISR/ISR
- * handlers.
- *
+ * handlers. *
  * @return 0 is returned on success. Otherwise, -EINVAL is returned if
  * a low-level error occurred while attaching the interrupt. -EBUSY is
  * specifically returned if the interrupt object was already attached.
@@ -204,11 +260,64 @@ int xnintr_destroy (xnintr_t *intr)
 int xnintr_attach (xnintr_t *intr,
 		   void *cookie)
 {
+    xnintr_shirq_t *shirq;
+    xnintr_t *prev, **p;
+    unsigned long flags;
+    int err = 0;
+
+    if (intr->irq >= XNARCH_NR_IRQS)
+	return -EINVAL;
+
     intr->hits = 0;
+    intr->next = NULL;
     intr->cookie = cookie;
-    return xnarch_hook_irq(intr->irq,&xnintr_irq_handler,intr->iack,intr);
+    shirq = &xnshirqs[intr->irq];
+
+    flags = xnarch_critical_enter(NULL);
+
+    if (test_and_set_bit(XN_ISR_ATTACHED,&intr->flags))
+	{
+	err = -EPERM;
+	goto unlock_and_exit;
+	}
+
+    p = &shirq->handlers;
+
+    if ((prev = *p) != NULL)
+	{
+	/* Check on whether the shared mode is allowed. */
+	if (!(prev->flags & intr->flags & XN_ISR_SHARED) || (prev->iack != intr->iack))
+	    {
+	    err = -EBUSY;
+	    goto unlock_and_exit;
+	    }
+
+	/* Get a position at the end of the list to insert the new element. */
+	while (prev)
+	    {
+	    p = &prev->next;
+	    prev = *p;
+	    }
+	}
+    else
+	{
+	/* Initialize the corresponding interrupt channel */
+	err = xnarch_hook_irq(intr->irq,&xnintr_shirq_handler,intr->iack,NULL);
+	if (err)
+	    goto unlock_and_exit;
+	}
+
+    /* Add a given interrupt object. */
+    *p = intr;
+
+unlock_and_exit:
+
+    xnarch_critical_exit(flags);
+    return err;
+
 }
 
+
 /*! 
  * \fn int xnintr_detach (xnintr_t *intr)
  * \brief Detach an interrupt object.
@@ -241,7 +350,51 @@ int xnintr_attach (xnintr_t *intr,
 int xnintr_detach (xnintr_t *intr)
 
 {
-    return xnarch_release_irq(intr->irq);
+    xnintr_shirq_t *shirq;
+    unsigned long flags;
+    xnintr_t *e, **p;
+    int err = 0;
+
+    if (intr->irq >= XNARCH_NR_IRQS)
+	return -EINVAL;
+
+    shirq = &xnshirqs[intr->irq];
+
+    flags = xnarch_critical_enter(NULL);
+
+    if (!test_and_clear_bit(XN_ISR_ATTACHED,&intr->flags))
+	{
+	xnarch_critical_exit(flags);
+	return -EPERM;
+	}
+
+    p = &shirq->handlers;
+
+    while ((e = *p) != NULL)
+	{
+	if (e == intr)
+	    {
+	    /* Remove a given interrupt object from the list. */
+	    if ((*p = e->next) == NULL)
+		err = xnarch_release_irq(intr->irq);
+    
+	    xnarch_critical_exit(flags);
+
+	    /* The idea here is to keep a detached interrupt object valid as long
+	       as the corresponding irq handler is running. This is one of the requirements
+	       to iterate over the xnintr_shirq_t::handlers list in xnintr_irq_handler()
+	       in a lockless way. */
+	    xnintr_shirq_spin(shirq);
+	    return err;
+	    }
+	p = &e->next;
+	}
+
+    xnarch_critical_exit(flags);
+
+    xnlogerr("Attempted to detach a non previously attached interrupt object");
+    return err;
+
 }
 
 /*! 
@@ -384,6 +537,50 @@ static void xnintr_irq_handler (unsigned
     xnltt_log_event(xeno_ev_iexit,irq);
 }
 
+static void xnintr_shirq_handler (unsigned irq, void *cookie)
+
+{
+    xnsched_t *sched = xnpod_current_sched();
+    xnintr_shirq_t *shirq;
+    xnintr_t *intr;
+    int s = 0;
+
+    xnarch_memory_barrier();
+
+    xnltt_log_event(xeno_ev_ienter,irq);
+
+    shirq = &xnshirqs[irq];
+    intr = shirq->handlers;
+
+    ++sched->inesting;
+
+    xnintr_shirq_lock(shirq);
+    
+    while (intr)
+	{
+	s |= intr->isr(intr);
+	++intr->hits;
+
+	intr = intr->next;
+	}
+
+    xnintr_shirq_unlock(shirq);
+
+    --sched->inesting;
+
+    if (s & XN_ISR_ENABLE)
+	xnarch_enable_irq(irq);
+
+    if (s & XN_ISR_CHAINED)
+	xnarch_chain_irq(irq);
+
+    if (sched->inesting == 0 && xnsched_resched_p())
+	xnpod_schedule();
+
+    xnltt_log_event(xeno_ev_iexit,irq);
+}
+
+
 /*@}*/
 
 EXPORT_SYMBOL(xnintr_attach);
diff -urp xenomai-cvs/ksrc/nucleus/module.c xenomai/ksrc/nucleus/module.c
--- xenomai-cvs/ksrc/nucleus/module.c	2005-11-30 10:36:33.000000000 +0100
+++ xenomai/ksrc/nucleus/module.c	2006-01-17 20:42:09.000000000 +0100
@@ -713,6 +713,8 @@ int __init __xeno_sys_init (void)
     xnpod_init_proc();
 #endif /* CONFIG_PROC_FS */
 
+    xnintr_mount();
+
 #ifdef CONFIG_LTT
     xnltt_mount();
 #endif /* CONFIG_LTT */

[Xenomai-core] Re: [PATCH] Shared irqs v.5

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1715 bytes --]

Dmitry Adamushko wrote:
> Hello Jan,
> 
> as I promised earlier today, here is the patch.

I finally had a look at your patch (not yet a try), and it looks really
nice and light-weight. Now I only have two topics on my wish list:

o Handling of edge-triggered IRQs (ISA-cards...). As I tried to explain,
  in this case we have to run the IRQ handler list as long as the full
  list completed without any handler reporting XN_ISR_ENABLE back. Then
  and only then we are safe to not stall the IRQ line. See e.g.
  serial8250_interrupt() in linux/drivers/serial/8250.c for a per-driver
  solution and [1] for some discussion on sharing IRQs (be warned, it's
  from the evil side ;) ).

  On our systems we already have two of those use-cases: the xeno_16550A
  handling up to 4 devices on the same IRQ on an ISA card (I don't want
  to know what worst-case latency can be caused here...) and our
  SJA-1000 CAN driver for PC/104 ISA card with 2 controllers on the same
  interrupt line. So a common solution would reduce the code size and
  potential bug sources.

o Store and display (/proc) the driver name(s) registered on an IRQ line
  somewhere (ipipe?). This is just a nice-to-have. I introduced the RTDM
  API with the required argument in place, would be great if we can use
  this some day.

BTW, making the RTDM API shirq-aware should be as easy as adding some
flags: one for sharing in general and maybe another one for marking
edge-triggered IRQs.

Jan


PS: Still at home? How many degrees Centigrade? I guess our current -9°C
here in Hannover must appear ridiculous, almost subtropical warm to you. ;)

[1] http://www.microsoft.com/whdc/system/sysperf/apic.mspx


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

[Xenomai-core] Re: [PATCH] Shared irqs v.5

[Dmitry Adamushko]

[-- Attachment #1: Type: text/plain, Size: 4758 bytes --]

On 23/01/06, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>
> Dmitry Adamushko wrote:
> > Hello Jan,
> >
> > as I promised earlier today, here is the patch.
>
> I finally had a look at your patch (not yet a try), and it looks really
> nice and light-weight.


I have another version here at hand. The only difference is that
xnintr_irq_handler() handles all interrupts and destinguished the timer
interrupt via "irq == XNARCH_TIMER_IRQ" to handle it appropriately. This
way, the i-cache is, hopefully, used a bit more effectively. But it doesn't
make a big difference in other parts of code so you may start testing with
the one I posted earlier.


Now I only have two topics on my wish list:
>
o Handling of edge-triggered IRQs (ISA-cards...). As I tried to explain,
>   in this case we have to run the IRQ handler list as long as the full
>   list completed without any handler reporting XN_ISR_ENABLE back. Then
>   and only then we are safe to not stall the IRQ line. See e.g.
>   serial8250_interrupt() in linux/drivers/serial/8250.c for a per-driver
>   solution and [1] for some discussion on sharing IRQs (be warned, it's
>   from the evil side ;) ).


Ok. e.g. we may introduce another flag to handle such a special case.
Something along XN_ISR_EDGETIRQ and maybe a separate
xnintr_etshirq_handler() (xnintr_attach() will set it up properly) so to
avoid interfering with another code. No big overhead I guess.
serial8250_interrupt() defines a maximum number of iterations so we should
do the same (?) to avoid brain-damaged cases.

  On our systems we already have two of those use-cases: the xeno_16550A
>   handling up to 4 devices on the same IRQ on an ISA card (I don't want
>   to know what worst-case latency can be caused here...) and our
>   SJA-1000 CAN driver for PC/104 ISA card with 2 controllers on the same
>   interrupt line. So a common solution would reduce the code size and
>   potential bug sources.
>
> o Store and display (/proc) the driver name(s) registered on an IRQ line
>   somewhere (ipipe?). This is just a nice-to-have. I introduced the RTDM
>   API with the required argument in place, would be great if we can use
>   this some day.


Yes, the proper /proc extension should be avalable. Actually, the "native"
skin can't be extended to support the shared interrupts only by adding a new
flag. The "problem" is the way the /proc/xenomai/registry/interrupts is
implemented there (and I assume any other skin follows the same way). The
rt_registry object is created per each RT_INTR structure and, hence, per
each xnintr_t.

I'd see the following scheme :

either

/proc/xenomai/interrupts lists all interrupts objects registered on the
nucleus layer (xnintr_t should have a "name" field).

IRQN      drivers

3              driver1
...
5              driver2, driver3

and the skin presents per-object information as

ll /proc/xenomai/registry/interrupts

driver1
driver2
driver3

each of those files contains the same information as now.

To achieve this,

1) xnintr_t should be extended with a "name" field;

2) rt_intr_create() should contain a "name" argument and not use
auto-generation (as "irqN") any more.

or

ll /proc/xenomai/registry/interrupts

3
5

Those are directories and e.g.

ll /proc/xenomai/registry/interrupts/5

driver2
driver3

Those are "files" and contain the same information as now.

This is harder to implement since the registry interface should be extended
(for each skin).


> ...

> Jan
>
>
> PS: Still at home?


Yes. This week I'm going to Belgium to attend a few meeting with some
customers of my potential employer. So my next step for the nearest future
will be finally determined there :)


How many degrees Centigrade? I guess our current -9°C
> here in Hannover must appear ridiculous, almost subtropical warm to you.
> ;)


Hey, I'm not from Syberia :o) This is a kind of common delusion I guess as
the whole former USSR is assotiated with cold winters, bears, eak.. KGB etc.
:o)

from wikipedia.com (about Belarus) :

"The climate <http://en.wikipedia.org/wiki/Climate> ranges from harsh
winters <http://en.wikipedia.org/wiki/Winter> (average January temperatures
are in the range −8 °C to −2 °C) to cool and moist
summers<http://en.wikipedia.org/wiki/Summer>(average temperature 15 °C
to 20 °C)."

Actually, last days it was very cooooold - even about -30C. This happens
from time to time but very rare (once in a few years or so) and it's not
considered as something normal here. e.g. schools were closed a few last
days when the temperature was below -25. Actually, the weather is getting
crazy last years and not only here :)

[1] http://www.microsoft.com/whdc/system/sysperf/apic.mspx
>
>
>

--
Best regards,
Dmitry Adamushko

[-- Attachment #2: Type: text/html, Size: 6904 bytes --]

[Xenomai-core] Re: [PATCH] Shared irqs v.5

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 5976 bytes --]

Dmitry Adamushko wrote:
> On 23/01/06, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>> Dmitry Adamushko wrote:
>>> Hello Jan,
>>>
>>> as I promised earlier today, here is the patch.
>> I finally had a look at your patch (not yet a try), and it looks really
>> nice and light-weight.
> 
> 
> I have another version here at hand. The only difference is that
> xnintr_irq_handler() handles all interrupts and destinguished the timer
> interrupt via "irq == XNARCH_TIMER_IRQ" to handle it appropriately. This
> way, the i-cache is, hopefully, used a bit more effectively. But it doesn't
> make a big difference in other parts of code so you may start testing with
> the one I posted earlier.
> 

I see: hunting the microsecond. ;)

> 
> Now I only have two topics on my wish list:
> o Handling of edge-triggered IRQs (ISA-cards...). As I tried to explain,
>>   in this case we have to run the IRQ handler list as long as the full
>>   list completed without any handler reporting XN_ISR_ENABLE back. Then
>>   and only then we are safe to not stall the IRQ line. See e.g.
>>   serial8250_interrupt() in linux/drivers/serial/8250.c for a per-driver
>>   solution and [1] for some discussion on sharing IRQs (be warned, it's
>>   from the evil side ;) ).
> 
> 
> Ok. e.g. we may introduce another flag to handle such a special case.
> Something along XN_ISR_EDGETIRQ and maybe a separate
> xnintr_etshirq_handler() (xnintr_attach() will set it up properly) so to
> avoid interfering with another code. No big overhead I guess.
> serial8250_interrupt() defines a maximum number of iterations so we should
> do the same (?) to avoid brain-damaged cases.

Might be useful for post-mortem analysis - most real-time system will
likely already have caused more or less severe damage after an IRQ
handler looped for 256 times or so. Anyway, if you are able to read some
information about this later on your console, it is better than not
knowing at all why your drilling machine just created an extra-deep hole.

> 
>   On our systems we already have two of those use-cases: the xeno_16550A
>>   handling up to 4 devices on the same IRQ on an ISA card (I don't want
>>   to know what worst-case latency can be caused here...) and our
>>   SJA-1000 CAN driver for PC/104 ISA card with 2 controllers on the same
>>   interrupt line. So a common solution would reduce the code size and
>>   potential bug sources.
>>
>> o Store and display (/proc) the driver name(s) registered on an IRQ line
>>   somewhere (ipipe?). This is just a nice-to-have. I introduced the RTDM
>>   API with the required argument in place, would be great if we can use
>>   this some day.
> 
> 
> Yes, the proper /proc extension should be avalable. Actually, the "native"
> skin can't be extended to support the shared interrupts only by adding a new
> flag. The "problem" is the way the /proc/xenomai/registry/interrupts is
> implemented there (and I assume any other skin follows the same way). The
> rt_registry object is created per each RT_INTR structure and, hence, per
> each xnintr_t.
> 
> I'd see the following scheme :
> 
> either
> 
> /proc/xenomai/interrupts lists all interrupts objects registered on the
> nucleus layer (xnintr_t should have a "name" field).
> 
> IRQN      drivers
> 
> 3              driver1
> ...
> 5              driver2, driver3
> 
> and the skin presents per-object information as
> 
> ll /proc/xenomai/registry/interrupts
> 
> driver1
> driver2
> driver3
> 
> each of those files contains the same information as now.
> 
> To achieve this,
> 
> 1) xnintr_t should be extended with a "name" field;
> 
> 2) rt_intr_create() should contain a "name" argument and not use
> auto-generation (as "irqN") any more.
> 
> or
> 
> ll /proc/xenomai/registry/interrupts
> 
> 3
> 5
> 
> Those are directories and e.g.
> 
> ll /proc/xenomai/registry/interrupts/5
> 
> driver2
> driver3
> 
> Those are "files" and contain the same information as now.
> 
> This is harder to implement since the registry interface should be extended
> (for each skin).

Isn't just the native skin using this registry? Anyway, as the preferred
way of registering IRQ handlers should be via RTDM, and RTDM does not
use the registry, go for the simplest solution. /proc/xenomai/interrupts
is more important in my eyes.

> 
> 
>> ...
> 
>> Jan
>>
>>
>> PS: Still at home?
> 
> 
> Yes. This week I'm going to Belgium to attend a few meeting with some
> customers of my potential employer. So my next step for the nearest future
> will be finally determined there :)

Best wishes! Just avoid too much extra work, here is already enough to
do. ;)

> 
> 
> How many degrees Centigrade? I guess our current -9^[$B!k^[(BC
>> here in Hannover must appear ridiculous, almost subtropical warm to you.
>> ;)
> 
> 
> Hey, I'm not from Syberia :o) This is a kind of common delusion I guess as
> the whole former USSR is assotiated with cold winters, bears, eak.. KGB etc.
> :o)

"Former"? Did I missed something? :)

> 
> from wikipedia.com (about Belarus) :
> 
> "The climate <http://en.wikipedia.org/wiki/Climate> ranges from harsh
> winters <http://en.wikipedia.org/wiki/Winter> (average January temperatures
> are in the range ^[$B!]^[(B8 ^[$B!k^[(BC to ^[$B!]^[(B2 ^[$B!k^[(BC) to cool and moist
> summers<http://en.wikipedia.org/wiki/Summer>(average temperature 15 ^[$B!k^[(BC
> to 20 ^[$B!k^[(BC)."
> 
> Actually, last days it was very cooooold - even about -30C. This happens
> from time to time but very rare (once in a few years or so) and it's not
> considered as something normal here. e.g. schools were closed a few last
> days when the temperature was below -25. Actually, the weather is getting
> crazy last years and not only here :)
> 
> [1] http://www.microsoft.com/whdc/system/sysperf/apic.mspx
>>
>>
> 
> --
> Best regards,
> Dmitry Adamushko
> 

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [Xenomai-core] Re: [PATCH] Shared irqs v.5

[Philippe Gerum]

Jan Kiszka wrote:
> Dmitry Adamushko wrote:

<snip>

>>
>>To achieve this,
>>
>>1) xnintr_t should be extended with a "name" field;
>>
>>2) rt_intr_create() should contain a "name" argument and not use
>>auto-generation (as "irqN") any more.
>>

Ok, sounds reasonable. This said, since this change would alter the interrupt API 
for the native skin, we should better do it asap, i.e. before 2.1 is out, so that 
we don't have to break the compatibility again in a few weeks/months. There is no 
urge to have the shared IRQ support available for 2.1, but the visible changes at 
the API level needed to have it in the future should be put in place early.

>>or
>>
>>ll /proc/xenomai/registry/interrupts
>>
>>3
>>5
>>
>>Those are directories and e.g.
>>
>>ll /proc/xenomai/registry/interrupts/5
>>
>>driver2
>>driver3
>>
>>Those are "files" and contain the same information as now.
>>
>>This is harder to implement since the registry interface should be extended
>>(for each skin).
> 
> 
> Isn't just the native skin using this registry? Anyway, as the preferred

(yep)

> way of registering IRQ handlers should be via RTDM, and RTDM does not
> use the registry, go for the simplest solution. /proc/xenomai/interrupts
> is more important in my eyes.
> 

Ack. The native skin is only one of the available interfaces, and IRQ channels are 
interface-independent resources, so this would be better controlled at nucleus 
level. As an aside, the POSIX skin is very important in the picture too, and 
getting full access to the shared IRQ support/features from there is utterly 
important.

> 
>>
>>>...
>>
>>>Jan
>>>
>>>
>>>PS: Still at home?
>>
>>
>>Yes. This week I'm going to Belgium to attend a few meeting with some
>>customers of my potential employer. So my next step for the nearest future
>>will be finally determined there :)
> 
> 
> Best wishes! Just avoid too much extra work, here is already enough to
> do. ;)
> 
> 
>>
>>How many degrees Centigrade? I guess our current -9^[$B!k^[(BC
>>
>>>here in Hannover must appear ridiculous, almost subtropical warm to you.
>>>;)
>>
>>
>>Hey, I'm not from Syberia :o) This is a kind of common delusion I guess as
>>the whole former USSR is assotiated with cold winters, bears, eak.. KGB etc.
>>:o)
> 
> 
> "Former"? Did I missed something? :)
> 
> 
>>from wikipedia.com (about Belarus) :
>>
>>"The climate <http://en.wikipedia.org/wiki/Climate> ranges from harsh
>>winters <http://en.wikipedia.org/wiki/Winter> (average January temperatures
>>are in the range ^[$B!]^[(B8 ^[$B!k^[(BC to ^[$B!]^[(B2 ^[$B!k^[(BC) to cool and moist
>>summers<http://en.wikipedia.org/wiki/Summer>(average temperature 15 ^[$B!k^[(BC
>>to 20 ^[$B!k^[(BC)."
>>
>>Actually, last days it was very cooooold - even about -30C. This happens
>>from time to time but very rare (once in a few years or so) and it's not
>>considered as something normal here. e.g. schools were closed a few last
>>days when the temperature was below -25. Actually, the weather is getting
>>crazy last years and not only here :)
>>
>>[1] http://www.microsoft.com/whdc/system/sysperf/apic.mspx
>>
>>>
>>--
>>Best regards,
>>Dmitry Adamushko
>>
> 
> 
> Jan
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@domain.hid
> https://mail.gna.org/listinfo/xenomai-core


-- 

Philippe.