Anders Blomdell wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Dmitry Adamushko wrote:
...
This said, I'm going to publish the shirq patch (after finalizing ISR
return
bits,
where I still have some doubts) without enable/disable nesting
support.
It can be supported
Anders Blomdell wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Dmitry Adamushko wrote:
...
This said, I'm going to publish the shirq patch (after finalizing ISR
return
bits,
where I still have some doubts) without enable/disable nesting
support.
It can be supported at
Dmitry Adamushko wrote:
...
This said, I'm going to publish 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.
Regarding enable/disable nesting
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Dmitry Adamushko wrote:
...
This said, I'm going to publish 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,
Dmitry Adamushko wrote:
For RTDM I'm now almost determined to rework the API in way that only
HANDLED/UNHANDLED (or what ever their names will be) get exported, any
additional guru features will remain excluded as long as we have no
clean usage policy for them.
Good. Then let's go for
Dmitry Adamushko wrote:
For RTDM I'm now almost determined to rework the API in way that only
HANDLED/UNHANDLED (or what ever their names will be) get exported, any
additional guru features will remain excluded as long as we have no
clean usage policy for them.
Good. Then let's go for
For RTDM I'm now almost determined to rework the API in way that only
HANDLED/UNHANDLED (or what ever their names will be) get exported, any
additional guru features will remain excluded as long as we have no
clean usage policy for them.
Good. Then let's go for
HANDLED, UNHANDLED - we may
Dmitry Adamushko wrote:
For RTDM I'm now almost determined to rework the API in way that only
HANDLED/UNHANDLED (or what ever their names will be) get exported, any
additional guru features will remain excluded as long as we have no
clean usage policy for them.
Good. Then let's go for
Dmitry Adamushko wrote:
For RTDM I'm now almost determined to rework the API in way that only
HANDLED/UNHANDLED (or what ever their names will be) get exported, any
additional guru features will remain excluded as long as we have no
clean usage policy for them.
Good. Then let's go for
For RTDM I'm now almost determined to rework the API in way that only
HANDLED/UNHANDLED (or what ever their names will be) get exported, any
additional guru features will remain excluded as long as we have no
clean usage policy for them.
Good. Then let's go for
HANDLED, UNHANDLED - we may
Dmitry Adamushko wrote:
For RTDM I'm now almost determined to rework the API in way that only
HANDLED/UNHANDLED (or what ever their names will be) get exported, any
additional guru features will remain excluded as long as we have no
clean usage policy for them.
Good. Then let's go for
Dmitry Adamushko wrote:
For RTDM I'm now almost determined to rework the API in way that only
HANDLED/UNHANDLED (or what ever their names will be) get exported, any
additional guru features will remain excluded as long as we have no
clean usage policy for them.
Good. Then let's go for
Anders Blomdell wrote:
Jan Kiszka wrote:
Hi Dmitry,
Dmitry Adamushko wrote:
Hi Jan,
let's make yet another revision of the bits :
new XN_ISR_HANDLED == old XN_ISR_HANDLED + old XN_ISR_NO_ENABLE
ok.
new XN_ISR_NOENABLE == ~ old XN_ISR_ENABLE
ok.
new XN_ISR_PROPAGATE ==
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 the
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 of the
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 of the shared handlers leaves the
Good point, leaves us with 2 possible return values for shared handlers:
HANDLED
NOT_HANDLED
i.e. shared handlers should never defer the end'ing of the interrupt (which
makes sense, since this would affect the other [shared] handlers).
HANDLED_NOEBNABLE could be supported too. There
Dmitry Adamushko wrote:
Good point, leaves us with 2 possible return values for shared handlers:
HANDLED
NOT_HANDLED
i.e. shared handlers should never defer the end'ing of the interrupt
(which
makes sense, since this would affect the other [shared] handlers).
Jan Kiszka wrote:
Anders Blomdell wrote:
Dmitry Adamushko wrote:
Good point, leaves us with 2 possible return values for shared
handlers:
HANDLED
NOT_HANDLED
i.e. shared handlers should never defer the end'ing of the
interrupt (which
makes sense, since this would affect the other
Anders Blomdell wrote:
Jan Kiszka wrote:
Hi Dmitry,
Dmitry Adamushko wrote:
Hi Jan,
let's make yet another revision of the bits :
new XN_ISR_HANDLED == old XN_ISR_HANDLED + old XN_ISR_NO_ENABLE
ok.
new XN_ISR_NOENABLE == ~ old XN_ISR_ENABLE
ok.
new XN_ISR_PROPAGATE ==
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 the interrupt
asserted,
returns
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 the
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 of the
Dmitry Adamushko wrote:
On 21/02/06, *Anders Blomdell* [EMAIL PROTECTED]
mailto:[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
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 of the shared handlers leaves the
Anders Blomdell wrote:
Dmitry Adamushko wrote:
On 21/02/06, *Anders Blomdell* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Dmitry Adamushko wrote:
N.B. Amongst other things, some thoughts about CHAINED with shared
interrupts.
On 20/02/06,
Good point, leaves us with 2 possible return values for shared handlers:
HANDLED
NOT_HANDLED
i.e. shared handlers should never defer the end'ing of the interrupt (which
makes sense, since this would affect the other [shared] handlers).
HANDLED_NOEBNABLE could be supported too. There
Dmitry Adamushko wrote:
Good point, leaves us with 2 possible return values for shared handlers:
HANDLED
NOT_HANDLED
i.e. shared handlers should never defer the end'ing of the interrupt
(which
makes sense, since this would affect the other [shared] handlers).
Anders Blomdell wrote:
Dmitry Adamushko wrote:
Good point, leaves us with 2 possible return values for shared
handlers:
HANDLED
NOT_HANDLED
i.e. shared handlers should never defer the end'ing of the
interrupt (which
makes sense, since this would affect the other
Jan Kiszka wrote:
Hi Dmitry,
Dmitry Adamushko wrote:
Hi Jan,
let's make yet another revision of the bits :
new XN_ISR_HANDLED == old XN_ISR_HANDLED + old XN_ISR_NO_ENABLE
ok.
new XN_ISR_NOENABLE == ~ old XN_ISR_ENABLE
ok.
new XN_ISR_PROPAGATE == XN_ISR_CHAINED
ok.
Just to make
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 the interrupt asserted,
returns NOENABLE|HANDLED and another return only
Hi Jan,
let's make yet another revision of the bits :
new XN_ISR_HANDLED == old XN_ISR_HANDLED + old XN_ISR_NO_ENABLE
ok.
new XN_ISR_NOENABLE == ~ old XN_ISR_ENABLE
ok.
new XN_ISR_PROPAGATE == XN_ISR_CHAINED
ok.
new XN_ISR_NOINT == ?
does it suppose the interrupt line to be .end-ed
Hi Dmitry,
Dmitry Adamushko wrote:
Hi Jan,
let's make yet another revision of the bits :
new XN_ISR_HANDLED == old XN_ISR_HANDLED + old XN_ISR_NO_ENABLE
ok.
new XN_ISR_NOENABLE == ~ old XN_ISR_ENABLE
ok.
new XN_ISR_PROPAGATE == XN_ISR_CHAINED
ok.
Just to make sure that
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
Dmitry Adamushko wrote:
Hello everybody,
being inspired by successful results of tests conducted recently by Jan
team,
I'm presenting the final (yep, yet another final :) combo-patch.
The shirq support now is optional, so that
CONFIG_XENO_OPT_SHIRQ_LEVEL -enables shirq for
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
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
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 XN_ISR_HANDLED non-zero)?
Ok, XN_ISR_NOINT is
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
Dmitry Adamushko wrote:
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
40 matches
Mail list logo
