On Thu, 2009-12-10 at 16:48 +0000, A C wrote: >> Hello, >> >> We started to port Adeos for the IRQs part. >> >> Simple question: Why the function raw_irqs_disabled_flags(flags) is >> the same with or without ipipe ? (as we saw in some arch). >>
>Because the pipeline code must guarantee that, for all standard linux >IRQ state accessors/modifiers (e.g. local_irq_save/restore(), >raw_irqs_disabled_flags()) the same values are used to assert/test the >interrupt on/off states (e.g. MSR_EE, X86_EFLAGS_IF and so on), in the >virtualized IRQ flags, than the real IRQ flags linux uses when the >pipeline is disabled, for any given arch.
>e.g. on x86, albeit ugly, it must be allowed to
open-code:
>> (in the case with ipipe) >> Why not use __ipipe_test_root() -in the same way as the function >> __raw_local_save_flags()- to write the new function >> raw_irqs_disabled_flags(flags)?
>Because this would break the above rule, since __ipipe_test_root() >returns 0/1.
Hello, Sorry but we do not still understand what is the exception with the function raw_irqs_disabled_flags(flags). In fact, we understand well all others functions (raw_local_irq_disable(), raw_local_irq_enable()...) in the two differents levels (virtualized IRQ flags and real IRQ flags). But with raw_irqs_disabled_flags(flags) we do not see the rule that we will break if it wasn't the same with the virtualized IRQ flags and with the real IRQ flags.