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 which is now
> non-zero.
> Actually, at first I wanted to make it just the other way about.

Hmm, thinking about this again, I would like to revert my suggestion in
favour of a third approach (trying to keep you busy ;) ).

Ok, you are wellcome :)

I didn't get it, at least while looking briefly. To make it a bit easier, at least for me, let's go another way.

At the left is the list of allowed values as Philippe pointed out.
At the right is another list which corresponds to the left one but when NOINT is used instead of HANDLED. Moreover, I have added another case - pure NOINT. The ISR says it's not mine and, well, it doesn't know whether it should be propagated or no
(ok, so far CHAINED standed for NOINT).

HANDLED                     ->  0
CHAINED                      ->  CHAINED | NOINT
                                    ->   NOINT

Could you provide the 3-d corresponding table using your new flags?

> xnintr_t contains just the link "char *name" as you suggested but RT_INTR
> contains the name[XNOBJECT_NAME_LEN] member (as it was before actually).
> If it's ok,  then I'll send um... yet another final patch that addresses
> both issues :)

I'm fine with this as well if you prefer it, no problem.

Yep, let's go this way.


Best regards,
Dmitry Adamushko

Reply via email to