Dmitry Adamushko wrote: > On 23/01/06, Jan Kiszka <[EMAIL PROTECTED]> 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°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) "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 −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 > Jan
signature.asc
Description: OpenPGP digital signature
