Re: [Xenomai-core] [draft PATCH] nested enable/disable irq calls

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 2215 bytes --]

Hi Dmitry,

Dmitry Adamushko wrote:
> Hi,
> 
> yep, this is yet another draft patch which aims at supporting the
> nested irq disable/enable calls for the primary domain.
> 
> o  no changes on the adeos-ipipe layer, hence it's much cleaner and
> smaller that the one I have posted last time;
> 
> o  eliminates the need for XN_ISR_NOENABLE flag;
> 
> o  but is based on the presupposition (otherwise it's wrong) that for
> all acrhitectures that support Xenomai the following is true :
> 
> 	pic_handler->ack :
> 	    * mask
> 	    * eoi
> 	
> 	pic_handler->end :
> 	    * unmask
> 	
> Philippe told me some time ago that this is a _must_ now for any arch
> to be compatible with adeos-ipipe.
> 
> If so, with some minor cleanups (XN_ISR_NOENABLE should be removed all
> over the map,
> docs fixes, ...) and testing the patch may hopefully find its way into
> the codebase.
> 
> Any feedback? 	
> 

Yes, I do have some remarks: due to legacy issues (I think to remember),
we have a lot of unbalanced irq-enable/disable code out there. IRQs are
currently enabled after registering a handler, but are not disabled on
detach. That's because of problems with Linux when letting it take over
a disabled IRQ, and for the sake of shared-irqs. Thus, if we introduce
such a nestable enable/disable, we _must_ think about managing the side
effects in legacy code (I haven't thought about this in details yet).


Another thing I have on my mind ATM is providing an additional IRQ
model: threaded IRQs. This is certainly not the best default model, but
it could help in certain scenarios to reduce prio-inversions due to
overloaded IRQ handler jobs (like we face from time to time with devices
on the slow ISA-bus...).

I think this should be rather simple to implement with the existing
infrastructure. I'm just wondering if it should become a RTDM or a
nucleus feature. Any opinions? [I'm currently in favour of RTDM.]

A nice add-on to this model would be to capture timestamps in the hard
stub and to distribute it to the threaded handlers. That's quite
egoistic, as it would perfectly fit our needs again: low timestamp
jitter but schedulable IRQ jobs. :)

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]