Re: [Xenomai-core] RTLWS 2005 - who plans to attend?

2005-10-21 Thread Dmitry Adamushko
On Wednesday 19 October 2005 20:56, you wrote: I've been to the RTLWS 2003 in Valencia, and it was great. A lot of interesting discussions with the inner circle, also from the other side ;) (RTLinux/GPL), and with users. And it was a nice place to stay, of course. Well, for me at least it

Re: [Xenomai-core] [RFC] support for sharing IRQs

2005-10-31 Thread Dmitry Adamushko
Hi Jan, I have some code hanging around here which implements IRQ sharing at skin level for an experimental in-house development over Xenomai. The code is smart enough to register an IRQ sharing trampoline handler only in case sharing is actually practiced for a specific line. Could you

Re: [Xenomai-core] [RFC] support for sharing IRQs

2005-11-01 Thread Dmitry Adamushko
On Tuesday 01 November 2005 10:49, you wrote: In that case, the nucleus must keep track of all the irqs, i.e. some_struct irqs[IPIPE_NR_IRQS]. Ok, the rthal_realtime_irq[] may be removed here from hal. But there is already the per-irq array in ipipe_domain struct. Having got [1] and [2]

Re: [Xenomai-core] [RFC] support for sharing IRQs

2005-11-01 Thread Dmitry Adamushko
On Tuesday 01 November 2005 12:58, you wrote: as cockie to the xnintr_irq_handler(). The analogy is irq_desc_t vs. irqaction structures in Linux. This way, xnintr_irq_handler() can be called from adeos-ipipe layer directly without the [2] layer. But that change looks quite

Re: [Xenomai-core] RTLWS 2005 - who plans to attend?

2005-11-01 Thread Dmitry Adamushko
Hi Jan and everybody, I would be happy to meet another Xenomai face in real there :). Actually, I can only come around on Friday, maybe already late Thursday evening (depends on the traffic...). The main reason for me to do this trip anyway is meeting new people. So, let's get together! Now

[Xenomai-core] Re: [Xenomai-help] printk

2005-11-14 Thread Dmitry Adamushko
... This cannot happen in async mode, since the output would be buffered and printk() never called on behalf of the preempted handler. let's say at the (*) point void __ipipe_flush_printk (unsigned virq) { char *p = __ipipe_printk_buf; int out = 0, len;

[Xenomai-core] [pipe.c] hairy synchronization - flush the output queue upon closure

2005-11-18 Thread Dmitry Adamushko
Hi, I failed to find the original message from Sebastian that led to the following change: - 2005-11-09 Philippe Gerum [EMAIL PROTECTED] * nucleus/pipe.c (xnpipe_disconnect): Flush the output queue upon closure. Issue spotted by Sebastian Smolorz.

Re: [Xenomai-core] Re: [Xenomai-help] Blocking reads from pipes

2005-11-18 Thread Dmitry Adamushko
[EMAIL PROTECTED] wrote on 18.11.2005 09:57:15: Exactly, I have just found out that and posted actually a long mail just before getting this mail from you :o) Yep, and before getting blocked, read() increments the counter as well, that's why we don't have a xnpipe_realease() called

[Xenomai-core] [rt shared irqs] ipipe-related changes (draft)

2005-12-26 Thread Dmitry Adamushko
shorter. Some points are more likely to be changed in the next iteration (e.g. __ipipe_irq_cookie() vs. changing the ipipe_virtualize_irq() interface). The struct rthal_realtime_irq::hits[per-IRQ] is missed so far. Anyway, comments are very wellcome. -- Best regards, Dmitry Adamushko diff -urp linux

[Xenomai-core] [rt shared irqs] changes on the adeos-ipipe layer v.2

2005-12-29 Thread Dmitry Adamushko
that sum of all apcs in /proc/xenomai/apc != virq from /proc/xenomai/irq, but ipipe_printk_virq is not listed since it's registered without rthal::apc interface. Ok, should take a look at it closer, i.e. maybe at least rthal_linux_irq can be reworked now. -- Best regards,Dmitry Adamushko ipipe

[Xenomai-core] [PATCH, RFC] nucleus:shared irq and possible ipipe problem

2005-12-31 Thread Dmitry Adamushko
gracefully I'd say. Ok, it's enough for the New Year's Eve. Happy New Year to everybody! I wish you all the best for the New Year :o) -- Best regards,Dmitry Adamushko nucleus_intr.c.patch Description: Binary data nucleus_intr.h.patch Description: Binary data

Re: [Xenomai-core] [rt shared irqs] changes on the adeos-ipipe layer v.2

2006-01-02 Thread Dmitry Adamushko
. when there is no APC interface yet, mea culpa. --Philippe.-- Best regards,Dmitry Adamushko ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core

[Xenomai-core] Re: [PATCH, RFC] nucleus:shared irq and possible ipipe problem

2006-01-06 Thread Dmitry Adamushko
On 05/01/06, Philippe Gerum [EMAIL PROTECTED] wrote: Dmitry Adamushko wrote: err... I have to orginize some issues next few days so I'll be out of my notebook. Then I'll finilize the ipipe-irq-related patch so to be ready for the .01 version. Meanwhile, I have finished merging the shared IRQ

[Xenomai-core] Re: [PATCH, RFC] nucleus:shared irq and possible ipipe problem

2006-01-09 Thread Dmitry Adamushko
regards, Dmitry Adamushko ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core

[Xenomai-core] [PATCH, RFC] nucleus:shared irq, draft v.2

2006-01-09 Thread Dmitry Adamushko
Hi everybody, I'm presenting it one last time as a draft, so it's a right time to give all the remarks concerning design/implementation issues for all interested parties. Any feedback is wellcome.-- Best regards,Dmitry Adamushko shirq_intr.h.patch Description: Binary data

[Xenomai-core] Re: nucleus:shared irq, draft v.2

2006-01-10 Thread Dmitry Adamushko
.. :) Jan -- Best regards, Dmitry Adamushko ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core

[Xenomai-core] Re: nucleus:shared irq, draft v.2

2006-01-10 Thread Dmitry Adamushko
On 09/01/06, Gilles Chanteperdrix [EMAIL PROTECTED] wrote: Dmitry Adamushko wrote: Hi everybody, I'm presenting it one last time as a draft, so it's a right time to give all the remarks concerning design/implementation issues for all interested parties. Any feedback

Re: [Xenomai-core] [PATCH, RFC] nucleus:shared irq, draft v.2

2006-01-11 Thread Dmitry Adamushko
On 09/01/06, Gilles Chanteperdrix [EMAIL PROTECTED] wrote: Dmitry Adamushko wrote: Hi everybody, I'm presenting it one last time as a draft, so it's a right time to give all the remarks concerning design/implementation issues for all interested parties. Any feedback is wellcome.Maybe I

[Xenomai-core] [PATCH] shared irqs v.3

2006-01-15 Thread Dmitry Adamushko
are not available. So consider it a temp solution for test purposes, I guess it's easily fixable. test/shirq.c - is a test module. SHIRQ_VECTOR must be the one used by Linux, e.g. I have used 12 that's used by the trackball device. -- Best regards,Dmitry Adamushko shirq-2_intr.c.patch Description: Binary

Re: [Xenomai-core] [PATCH] shared irqs v.3

2006-01-18 Thread Dmitry Adamushko
and list iterations for non-shared IRQs. What do you think? Worth it? Might be when the ISA/edge handling adds further otherwise unneeded overhead. Yep, maybe. But let's take something working first.. Jan -- Best regards,Dmitry Adamushko ___ Xenomai

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

2006-01-23 Thread Dmitry Adamushko
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 reallynice and light-weight. I have another version here at hand. The only difference

Re: [Xenomai-core] [BUG] racy xnshadow_harden under CONFIG_PREEMPT

2006-01-30 Thread Dmitry Adamushko
one else who has written that nonsense :o) -- Best regards, Dmitry AdamushkoJan-- Best regards,Dmitry Adamushko ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] [BUG] racy xnshadow_harden under CONFIG_PREEMPT

2006-01-30 Thread Dmitry Adamushko
On 30/01/06, Jan Kiszka [EMAIL PROTECTED] wrote: Dmitry Adamushko wrote: ... I have not checked it yet but my presupposition that something as easy as : preempt_disable() wake_up_interruptible_sync(); schedule(); preempt_enable(); It's a no-go: scheduling while atomic. One of my first attempts

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

2006-01-31 Thread Dmitry Adamushko
Hi, the previous version contained an ugly bug, namely the misuse of the test_and_set/clear_bit interface that led to a broken system from time to time. -- Best regards,Dmitry Adamushko shirq-v6.patch Description: Binary data ___ Xenomai-core

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

2006-01-31 Thread Dmitry Adamushko
On 31/01/06, Jan Kiszka [EMAIL PROTECTED] wrote: Dmitry Adamushko wrote: Hi, the previous version contained an ugly bug, namely the misuse of the test_and_set/clear_bit interface that led to a broken system from time to time. What about the ISA/edge-triggered stuff? :DMy problem is that we cannot

[Xenomai-core] [Combo-PATCH] Shared interrupts (final)

2006-02-07 Thread Dmitry Adamushko
to be applied as follows : - shirq-base - shirq-v8 - shirq-proc - shirq-edge - shirq-ext Happy testing ! :) -- Best regards,Dmitry Adamushko shirq-base.patch Description: Binary data shirq-v8.patch Description: Binary data shirq-proc.patch Description: Binary data shirq-edge.patch Description

Re: [Xenomai-core] [Combo-PATCH] Shared interrupts (final)

2006-02-07 Thread Dmitry Adamushko
(~1 for UP and ~2 for SMP) KBs of data are not that critical taking into account where and how they are used, both latency and cache-wise. Wolfgang. -- Best regards, Dmitry Adamushko

Re: [Xenomai-core] [Combo-PATCH] Shared interrupts (final)

2006-02-08 Thread Dmitry Adamushko
a close-to-zero-overhead should be made optional. Ok, let's go for it upon getting the test results. Enclosed a small optimization to reduce the code in (optional in future) ISR. Jan -- Best regards,Dmitry Adamushko shirq-v9.patch Description: Binary data

[Xenomai-core] Benchmarks

2006-02-09 Thread Dmitry Adamushko
comments on the one with a given number of threads are wellcome too. -- Best regards,Dmitry Adamushko ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core

[Xenomai-core] Re: More on Shared interrupts

2006-02-11 Thread Dmitry Adamushko
it was signaled. I guess, it's not true for devices that e.g. do not rise a new interrupt until the ISR handler does some special acknowledgement device-wise. am I right? -- Best regards,Dmitry Adamushko ___ Xenomai-core mailing list Xenomai-core@gna.org

[Xenomai-core] Re: [shirq] first test results

2006-02-11 Thread Dmitry Adamushko
On 11/02/06, Jan Kiszka [EMAIL PROTECTED] wrote: Dmitry Adamushko wrote: And as an additional option, it could be interesting to print out to the log if not all counter values then min,max,average (the same like for the latency :) per second or per 1000 interrupts; so to see whether tweaking

Re: [Xenomai-core] Re: [shirq] first test results

2006-02-14 Thread Dmitry Adamushko
On 13/02/06, Jan Kiszka [EMAIL PROTECTED] wrote: Dmitry Adamushko wrote: On 11/02/06, Jan Kiszka [EMAIL PROTECTED] wrote: Dmitry Adamushko wrote: And as an additional option, it could be interesting to print out to the log if not all counter values then min,max,average (the same like

[Xenomai-core] [PATCH] Shared interrupts (ready to merge)

2006-02-15 Thread Dmitry Adamushko
; CONFIG_XENO_OPT_SHIRQ_EDGE - -//- for edge-triggered ones. I addressed all the remarks and now, IMHO, it's (hopefully) ready for merge. -- Best regards,Dmitry Adamushko shirq-combo.patch Description: Binary data shirq-KConfig.patch Description: Binary data ChangeLog.patch Description: Binary data

Re: [Xenomai-core] Re: [PATCH] Shared interrupts (ready to merge)

2006-02-16 Thread Dmitry Adamushko
On 16/02/06, Jan Kiszka [EMAIL PROTECTED] wrote: Dmitry Adamushko wrote: On 16/02/06, Jan Kiszka [EMAIL PROTECTED] wrote: Dmitry Adamushko wrote: On 16/02/06, Jan Kiszka [EMAIL PROTECTED] wrote: Hmm, I still find XN_ISR_NOINT in the patch. Shouldn't we solve this before merging (i.e. make

Re: [Xenomai-core] Re: [PATCH] Shared interrupts (ready to merge)

2006-02-21 Thread Dmitry Adamushko
On 21/02/06, Jan Kiszka [EMAIL PROTECTED] wrote: Dmitry Adamushko wrote: N.B. Amongst other things, some thoughts about CHAINED with shared interrupts. On 20/02/06, Anders Blomdell [EMAIL PROTECTED] wrote: A number of questions arise: 1. What happens if one of the shared handlers leaves

Re: [Xenomai-core] Re: [PATCH] Shared interrupts (ready to merge)

2006-02-21 Thread Dmitry Adamushko
On 21/02/06, Anders Blomdell [EMAIL PROTECTED] wrote: Dmitry Adamushko wrote: N.B. Amongst other things, some thoughts about CHAINED with shared interrupts. On 20/02/06, *Anders Blomdell* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: A number of questions arise: 1. What happens if one

Re: [Xenomai-core] Re: [PATCH] Shared interrupts (ready to merge)

2006-02-21 Thread Dmitry Adamushko
,Dmitry Adamushko ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] Re: [PATCH] Shared interrupts (ready to merge)

2006-02-22 Thread Dmitry Adamushko
to lost interrupts on some archs. Moreover, it avoids the need for ENABLE flag even in non-shared interrupt case. -- Best regards,Dmitry Adamushko ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core

[Xenomai-core] [arm/hal.c] possible problem (and a PIC-related observation in vanilla Linux)

2006-02-24 Thread Dmitry Adamushko
y enable (e.g. enable_irq() - handler-enable() in bottom half) Could it be such an arch feature? It looks to me that it's logically wrong anyway. Heh... if one is still reading these lines, thanks for your time indeed! :o) -- Best regards,Dmitry Adamushko __

Re: [Xenomai-core] Re: [PATCH] Shared interrupts (ready to merge)

2006-02-25 Thread Dmitry Adamushko
the shirq patch (after finalizing ISR return bits, where I still have some doubts) without enable/disable nesting support. It can be supported at some point of time later, if it's really needed. --Philippe.-- Best regards, Dmitry Adamushko ___ Xenomai

[Xenomai-core] [PATCH] Shared interrupts (yet another movie :)

2006-02-27 Thread Dmitry Adamushko
is not yet clear at the moment. That's it... Ok, are there any objections as to the current patch? If no, please apply. CHANGELOG.patch is here https://mail.gna.org/public/xenomai-core/2006-02/msg00154.html -- Best regards,Dmitry Adamushko shirq-combo.patch Description: Binary data shirq

[Xenomai-core] Re: [PATCH] Shared interrupts (yet another movie :)

2006-02-28 Thread Dmitry Adamushko
On 28/02/06, Jan Kiszka [EMAIL PROTECTED] wrote: Dmitry Adamushko wrote: ... Ok, are there any objections as to the current patch? If no, please apply.Oops, I found a minor problem:make[2]: Entering directory `/usr/src/xenomai/build/doc/doxygen' doxygen/usr/src/xenomai/ksrc/skins/native/intr.c:523

Re: [Xenomai-core] 16550 compile err: ?RTDM_IRQ_ENABLE? undeclared (first use in this function)

2006-03-01 Thread Dmitry Adamushko
| RTDM_IRQ_HANDLED; +ret = RTDM_IRQ_HANDLED; } if (ctx-in_nwait 0) { My fault, sorry. I should have fixed that but overlooked again. Jan-- Best regards,Dmitry Adamushko ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core

[Xenomai-core] [PATCH] hal/arm : rthal_irq_enable/disable/end corrections

2006-03-01 Thread Dmitry Adamushko
,Dmitry Adamushko arm-hal.c.patch Description: Binary data ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core

[Xenomai-core] Re: [Xenomai-help] rt_task_wait_period() and overruns

2006-03-01 Thread Dmitry Adamushko
. Ok, some paranoid programmers would think differently even then but there is always the (*) way :o) -- Best regards,Dmitry Adamushko ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core

[Xenomai-core] Re: [Xenomai-help] rt_task_wait_period() and overruns

2006-03-01 Thread Dmitry Adamushko
On 01/03/06, Philippe Gerum [EMAIL PROTECTED] wrote: Dmitry Adamushko wrote: On 01/03/06, *Philippe Gerum* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: The other option I've described for dealing with overruns in rt_task_wait_period would be as follows: - save the count of overruns - clear

[Xenomai-core] [RFC, Experimental Patch] nested irq disable calls

2006-03-03 Thread Dmitry Adamushko
int xnintr_shirq_detach (xnintr_t *intr) return err; } +static void xnintr_synchronize (xnintr_t *intr) +{ + xnintr_shirq_spin(xnshirqs[intr-irq]); +} + int xnintr_mount(void) { int i; --- -- Best regards,Dmi

Re: [Xenomai-core] [RFC, Experimental Patch] nested irq disable calls

2006-03-07 Thread Dmitry Adamushko
to store the nesting counter becomes an option, I guess. Let's start from defining possible use cases with nested irq enable/disable calls then. Maybe we just don't need them at all (at least the same way Linux deals with them)? -- Philippe. -- Best regards,Dmitry Adamushko

[Xenomai-core] [PATCH] shirq correction

2006-03-11 Thread Dmitry Adamushko
Hello, I overlooked that the logic of decrementing the interrupt nesting count has been changed recently and both xnintr_shirq_handler() and xnintr_edge_shirq_handler() behave wrong in this respect. The attached patch fixes this misbehavior. -- Best regards,Dmitry Adamushko intr.c.patch

[Xenomai-core] [Combo-PATCH] Shared interrupts (base, /proc support, edge-triggered stuff)

2006-02-01 Thread Dmitry Adamushko
-triggered stuff. This is a very preliminary version so the only thing I promise so far is that it compiles successfully. The functionality added by first 3 patches seem to be working.-- Best regards,Dmitry Adamushko shirq-base.patch Description: Binary data shirq-v7.patch Description: Binary

Re: [Xenomai-core] [Combo-PATCH] Shared interrupts (base, /proc support, edge-triggered stuff)

2006-02-02 Thread Dmitry Adamushko
On 02/02/06, Jan Kiszka [EMAIL PROTECTED] wrote: Dmitry Adamushko wrote: Hi there, as I promised, here go the following patches (ordered as they have to be applied one by one) : 1) shirq-base.patch Adds the name field to the interrupt object of the nucleus layer. Reworks the related bits

Re: [Xenomai-core] [Combo-PATCH] Shared interrupts (final)

2006-02-07 Thread Dmitry Adamushko
(~1 for UP and ~2 for SMP) KBs of data are not that critical taking into account where and how they are used, both latency and cache-wise. Wolfgang. -- Best regards, Dmitry Adamushko

Re: [Xenomai-core] [Combo-PATCH] Shared interrupts (final)

2006-02-08 Thread Dmitry Adamushko
a close-to-zero-overhead should be made optional. Ok, let's go for it upon getting the test results. Enclosed a small optimization to reduce the code in (optional in future) ISR. Jan -- Best regards,Dmitry Adamushko shirq-v9.patch Description: Binary data

Re: [Xenomai-core] [Combo-PATCH] Shared interrupts (final)

2006-02-09 Thread Dmitry Adamushko
,Dmitry Adamushko

[Xenomai-core] Benchmarks

2006-02-09 Thread Dmitry Adamushko
comments on the one with a given number of threads are wellcome too. -- Best regards,Dmitry Adamushko

[Xenomai-core] Re: [shirq] first test results

2006-02-11 Thread Dmitry Adamushko
/syscall.c : __rt_intr_create()) so the initial copy of the name can not remain valid. Thanks for the patches. Jan -- Best regards,Dmitry Adamushko

[Xenomai-core] Re: More on Shared interrupts

2006-02-11 Thread Dmitry Adamushko
it was signaled. I guess, it's not true for devices that e.g. do not rise a new interrupt until the ISR handler does some special acknowledgement device-wise. am I right? -- Best regards,Dmitry Adamushko

[Xenomai-core] Re: [shirq] first test results

2006-02-11 Thread Dmitry Adamushko
On 11/02/06, Jan Kiszka [EMAIL PROTECTED] wrote: Dmitry Adamushko wrote: And as an additional option, it could be interesting to print out to the log if not all counter values then min,max,average (the same like for the latency :) per second or per 1000 interrupts; so to see whether tweaking

[Xenomai-core] Re: More on Shared interrupts

2006-02-13 Thread Dmitry Adamushko
On 13/02/06, Anders Blomdell [EMAIL PROTECTED] wrote: Dmitry Adamushko wrote: irq K| --- | ---o| // Linux only ... irq L| ---o| | // RT-only ... irq M| ---o--- | ---o| // Shared between domains ... irq N| ---o---o--- | | // Shared inside single domain ... irq O| ---o---o

Re: [Xenomai-core] Re: [shirq] first test results

2006-02-14 Thread Dmitry Adamushko
On 13/02/06, Jan Kiszka [EMAIL PROTECTED] wrote: Dmitry Adamushko wrote: On 11/02/06, Jan Kiszka [EMAIL PROTECTED] wrote: Dmitry Adamushko wrote: And as an additional option, it could be interesting to print out to the log if not all counter values then min,max,average (the same like

[Xenomai-core] [PATCH] Shared interrupts (ready to merge)

2006-02-15 Thread Dmitry Adamushko
; CONFIG_XENO_OPT_SHIRQ_EDGE - -//- for edge-triggered ones. I addressed all the remarks and now, IMHO, it's (hopefully) ready for merge. -- Best regards,Dmitry Adamushko shirq-combo.patch Description: Binary data shirq-KConfig.patch Description: Binary data ChangeLog.patch Description: Binary data

[Xenomai-core] Re: [PATCH] Shared interrupts (ready to merge)

2006-02-16 Thread Dmitry Adamushko
,Dmitry Adamushko

Re: [Xenomai-core] Re: [PATCH] Shared interrupts (ready to merge)

2006-02-16 Thread Dmitry Adamushko
On 16/02/06, Jan Kiszka [EMAIL PROTECTED] wrote: Dmitry Adamushko wrote: On 16/02/06, Jan Kiszka [EMAIL PROTECTED] wrote: Hmm, I still find XN_ISR_NOINT in the patch. Shouldn't we solve this before merging ( i.e. make XN_ISR_HANDLED non-zero)? Ok, XN_ISR_NOINT is removed in favor of XN_ISR_HANDLED

Re: [Xenomai-core] Re: [PATCH] Shared interrupts (ready to merge)

2006-02-16 Thread Dmitry Adamushko
On 16/02/06, Jan Kiszka [EMAIL PROTECTED] wrote: Dmitry Adamushko wrote: On 16/02/06, Jan Kiszka [EMAIL PROTECTED] wrote: Dmitry Adamushko wrote: On 16/02/06, Jan Kiszka [EMAIL PROTECTED] wrote: Hmm, I still find XN_ISR_NOINT in the patch. Shouldn't we solve this before merging (i.e. make

Re: [Xenomai-core] Re: [PATCH] Shared interrupts (ready to merge)

2006-02-18 Thread Dmitry Adamushko
consider HANDLED == 1 and NOINT == 0 as really scalar values and NOENABLE and PROPAGATE as additional bits (used only if needed). -- Best regards,Dmitry Adamushko

Re: [Xenomai-core] Re: [PATCH] Shared interrupts (ready to merge)

2006-02-20 Thread Dmitry Adamushko
on this line, otherwise that may lead to the IRQ line being .end-ed twice (lost interrupts in some cases). #define UNHANDLED 0#define HANDLED_ENABLE 1#define HANDLED_NOENABLE 2#define PROPAGATE 3 Yep, I'd agree with you. Moreover, PROPAGATE should not be used for shared interrupts. -- Best regards,Dmitry

Re: [Xenomai-core] Re: [PATCH] Shared interrupts (ready to merge)

2006-02-21 Thread Dmitry Adamushko
On 21/02/06, Jan Kiszka [EMAIL PROTECTED] wrote: Dmitry Adamushko wrote: N.B. Amongst other things, some thoughts about CHAINED with shared interrupts. On 20/02/06, Anders Blomdell [EMAIL PROTECTED] wrote: A number of questions arise: 1. What happens if one of the shared handlers leaves

Re: [Xenomai-core] Re: [PATCH] Shared interrupts (ready to merge)

2006-02-21 Thread Dmitry Adamushko
On 21/02/06, Anders Blomdell [EMAIL PROTECTED] wrote: Dmitry Adamushko wrote: N.B. Amongst other things, some thoughts about CHAINED with shared interrupts. On 20/02/06, *Anders Blomdell* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: A number of questions arise: 1. What happens if one

Re: [Xenomai-core] Re: [PATCH] Shared interrupts (ready to merge)

2006-02-21 Thread Dmitry Adamushko
,Dmitry Adamushko

Re: [Xenomai-core] Re: [PATCH] Shared interrupts (ready to merge)

2006-02-22 Thread Dmitry Adamushko
to lost interrupts on some archs. Moreover, it avoids the need for ENABLE flag even in non-shared interrupt case. -- Best regards,Dmitry Adamushko

[Xenomai-core] [PATCH, RFC] nucleus:shared irq and possible ipipe problem

2005-12-31 Thread Dmitry Adamushko
gracefully I'd say. Ok, it's enough for the New Year's Eve. Happy New Year to everybody! I wish you all the best for the New Year :o) -- Best regards,Dmitry Adamushko nucleus_intr.c.patch Description: Binary data nucleus_intr.h.patch Description: Binary data

Re: [Xenomai-core] [rt shared irqs] changes on the adeos-ipipe layer v.2

2006-01-02 Thread Dmitry Adamushko
. when there is no APC interface yet, mea culpa. --Philippe.-- Best regards,Dmitry Adamushko

[Xenomai-core] Re: [PATCH, RFC] nucleus:shared irq and possible ipipe problem

2006-01-06 Thread Dmitry Adamushko
On 05/01/06, Philippe Gerum [EMAIL PROTECTED] wrote: Dmitry Adamushko wrote: err... I have to orginize some issues next few days so I'll be out of my notebook. Then I'll finilize the ipipe-irq-related patch so to be ready for the .01 version. Meanwhile, I have finished merging the shared IRQ

[Xenomai-core] Re: nucleus:shared irq, draft v.2

2006-01-10 Thread Dmitry Adamushko
On 09/01/06, Gilles Chanteperdrix [EMAIL PROTECTED] wrote: Dmitry Adamushko wrote: Hi everybody, I'm presenting it one last time as a draft, so it's a right time to give all the remarks concerning design/implementation issues for all interested parties. Any feedback

[Xenomai-core] Re: nucleus:shared irq, draft v.2

2006-01-10 Thread Dmitry Adamushko
.. :) Jan -- Best regards, Dmitry Adamushko

Re: [Xenomai-core] [PATCH] shared irqs v.3

2006-01-18 Thread Dmitry Adamushko
and list iterations for non-shared IRQs. What do you think? Worth it? Might be when the ISA/edge handling adds further otherwise unneeded overhead. Yep, maybe. But let's take something working first.. Jan -- Best regards,Dmitry Adamushko

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

2006-01-18 Thread Dmitry Adamushko
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 shirq-v4.patch Description: Binary data

Re: [Xenomai-core] [BUG] racy xnshadow_harden under CONFIG_PREEMPT

2006-01-22 Thread Dmitry Adamushko
, but this could easily break the Linux scheduler. I have a stupid idea on top of my head but I'd prefer to test it on my own first so not to look as a complete idiot if it's totally wrong. Err... it's difficult to look more an idiot than I'm already? :o) Jan -- Best regards,Dmitry Adamushko

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

2006-01-23 Thread Dmitry Adamushko
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 reallynice and light-weight. I have another version here at hand. The only difference

Re: [Xenomai-core] [BUG] racy xnshadow_harden under CONFIG_PREEMPT

2006-01-24 Thread Dmitry Adamushko
blame me if no, it's some one else who has written that nonsense :o) -- Best regards,Dmitry Adamushko

Re: [Xenomai-core] [BUG] racy xnshadow_harden under CONFIG_PREEMPT

2006-01-30 Thread Dmitry Adamushko
one else who has written that nonsense :o) -- Best regards, Dmitry AdamushkoJan-- Best regards,Dmitry Adamushko

Re: [Xenomai-core] [BUG] racy xnshadow_harden under CONFIG_PREEMPT

2006-01-30 Thread Dmitry Adamushko
On 30/01/06, Jan Kiszka [EMAIL PROTECTED] wrote: Dmitry Adamushko wrote: ... I have not checked it yet but my presupposition that something as easy as : preempt_disable() wake_up_interruptible_sync(); schedule(); preempt_enable(); It's a no-go: scheduling while atomic. One of my first attempts

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

2006-01-31 Thread Dmitry Adamushko
Hi, the previous version contained an ugly bug, namely the misuse of the test_and_set/clear_bit interface that led to a broken system from time to time. -- Best regards,Dmitry Adamushko shirq-v6.patch Description: Binary data

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

2006-01-31 Thread Dmitry Adamushko
On 31/01/06, Jan Kiszka [EMAIL PROTECTED] wrote: Dmitry Adamushko wrote: Hi, the previous version contained an ugly bug, namely the misuse of the test_and_set/clear_bit interface that led to a broken system from time to time. What about the ISA/edge-triggered stuff? :DMy problem is that we cannot

[Xenomai-core] [rt shared irqs] ipipe-related changes (draft)

2005-12-26 Thread Dmitry Adamushko
shorter. Some points are more likely to be changed in the next iteration (e.g. __ipipe_irq_cookie() vs. changing the ipipe_virtualize_irq() interface). The struct rthal_realtime_irq::hits[per-IRQ] is missed so far. Anyway, comments are very wellcome. -- Best regards, Dmitry Adamushko diff -urp linux

[Xenomai-core] [rt shared irqs] changes on the adeos-ipipe layer v.2

2005-12-29 Thread Dmitry Adamushko
that sum of all apcs in /proc/xenomai/apc != virq from /proc/xenomai/irq, but ipipe_printk_virq is not listed since it's registered without rthal::apc interface. Ok, should take a look at it closer, i.e. maybe at least rthal_linux_irq can be reworked now. -- Best regards,Dmitry Adamushko ipipe

Re: [Xenomai-core] [RFC] support for sharing IRQs

2005-10-31 Thread Dmitry Adamushko
Hi Jan, I have some code hanging around here which implements IRQ sharing at skin level for an experimental in-house development over Xenomai. The code is smart enough to register an IRQ sharing trampoline handler only in case sharing is actually practiced for a specific line. Could you

Re: [Xenomai-core] [RFC] support for sharing IRQs

2005-10-31 Thread Dmitry Adamushko
On Monday 31 October 2005 16:04, you wrote: Dmitry Adamushko wrote: It seems to me now, that some parts of the hal will be involved (rthal_irq_request/release()) since the nucleus itself doesn't keep track of registered irqs. That's true. And it also raises another question to me: why do

Re: [Xenomai-core] [RFC] support for sharing IRQs

2005-10-31 Thread Dmitry Adamushko
On Monday 31 October 2005 21:38, you wrote: [...] In our case, the relation between xnintr_irq_handler() and rthal_irq_trampoline() is 1:1. The first one does much more things that the second one which is really almost a pure redirection layer. Hopefully, xnintr_irq_handler() is

Re: [Xenomai-core] [RFC] support for sharing IRQs

2005-11-01 Thread Dmitry Adamushko
On Tuesday 01 November 2005 10:49, you wrote: In that case, the nucleus must keep track of all the irqs, i.e. some_struct irqs[IPIPE_NR_IRQS]. Ok, the rthal_realtime_irq[] may be removed here from hal. But there is already the per-irq array in ipipe_domain struct. Having got [1] and [2]

Re: [Xenomai-core] [RFC] support for sharing IRQs

2005-11-01 Thread Dmitry Adamushko
On Tuesday 01 November 2005 12:58, you wrote: as cockie to the xnintr_irq_handler(). The analogy is irq_desc_t vs. irqaction structures in Linux. This way, xnintr_irq_handler() can be called from adeos-ipipe layer directly without the [2] layer. But that change looks quite

Re: [Xenomai-core] RTLWS 2005 - who plans to attend?

2005-11-01 Thread Dmitry Adamushko
Hi Jan and everybody, I would be happy to meet another Xenomai face in real there :). Actually, I can only come around on Friday, maybe already late Thursday evening (depends on the traffic...). The main reason for me to do this trip anyway is meeting new people. So, let's get together! Now

[Xenomai-core] Re: [Xenomai-help] printk

2005-11-15 Thread Dmitry Adamushko
please see comments below... Another approach is about dropping the non-atomic update sequence that hurts, tolerating null runs of the virq when the seldom preemption case is seen, but without requiring hw interrupt masking to protect the shared stuff. Livelocking Linux inside the

[Xenomai-core] [PATCH] Auto-allocation of minor values for pipe objects

2005-11-15 Thread Dmitry Adamushko
Hello, enclosed please find a patch that hopefully adds so desired functionality. I have made various tests with it just now and it seems to work fine. A size of the bitmap is dependent on XNPIPE_NDEVS parameter in the same vein as xnpipe_states depends on it; so hopefully that is what you

Re: [Xenomai-core] Question about shadow migration

2005-11-16 Thread Dmitry Adamushko
[EMAIL PROTECTED] wrote on 16.11.2005 09:09:07: The question for me is now if I got these details right: first a migration request is issued [1] but not immediately executed, This request is about scheduling an APC for execution (which is lostage_apc in that case). The APC mechanism is

[Xenomai-core] Re: [PATCH] Auto-allocation of minor values for pipe objects

2005-11-16 Thread Dmitry Adamushko
Philippe Gerum [EMAIL PROTECTED] wrote on 15.11.2005 23:17:50: Dmitry Adamushko wrote: Hello, enclosed please find a patch that hopefully adds so desired functionality. I have made various tests with it just now and it seems to work fine. Sounds good. A size

[Xenomai-core] Re: [Xenomai-help] printk

2005-11-16 Thread Dmitry Adamushko
Philippe Gerum [EMAIL PROTECTED] wrote on 16.11.2005 13:58:45: ... Ok, this kind of stuff should always be designed with the brain turned on. Now that I have eventually found the power switch, I'm going to fix the printk issue in the Adeos core along the following lines. The code below

Re: [Xenomai-core] Official logo

2005-11-16 Thread Dmitry Adamushko
Hi Bruno, I have a few remarks on the new web-site :) - lots of blank space at the bottom/left/right side of the page (width is about 3 cm. approx.) err.. is it really necessary (functionality or design-wise)? ok, it's difficult to argue on the design side since it's, well, very subjective

[Xenomai-core] Re: [Xenomai-help] Blocking reads from pipes

2005-11-17 Thread Dmitry Adamushko
On Thursday 17 November 2005 18:24, Gilles Chanteperdrix wrote: Dmitry Adamushko wrote: As a conclusion, the behaviour that you observed with Xenomai pipes seems consistent with that of Linux' named pipes, except that in Linux read() returns 0, and not an error code as you

[Xenomai-core] Re: [Xenomai-help] Blocking reads from pipes

2005-11-17 Thread Dmitry Adamushko
On Thursday 17 November 2005 18:24, Gilles Chanteperdrix wrote: Dmitry Adamushko wrote: As a conclusion, the behaviour that you observed with Xenomai pipes seems consistent with that of Linux' named pipes, except that in Linux read() returns 0, and not an error code as you

  1   2   >