On 23/01/06, Jan Kiszka <[EMAIL PROTECTED]> wrote:
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.
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.
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).
> ...
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 :)
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 ranges from harsh winters (average January temperatures are in the range −8 °C to −2 °C) to cool and moist summers (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 :)
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
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 ranges from harsh winters (average January temperatures are in the range −8 °C to −2 °C) to cool and moist summers (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
_______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
