Philippe Gerum wrote: > On Mon, 2009-11-09 at 14:37 +0100, Philippe Gerum wrote: >> On Mon, 2009-11-09 at 14:00 +0100, Jan Kiszka wrote: >>> Hi Philippe, >>> >>> a customer just stumbled over some unclear spots in current I-pipe patches: >>> >>> Why is there local_irq_enable_hw in task_hijacked? Looks like it was >>> once paired with prepare_arch_switch, but that call is now only used by >>> legacy 2.4 PPC. >> It is still used in all trees, since we define it in asm/ipipe.h. We >> could not context switch properly on the linux side with hw interrupts >> on anyway, due to the conflicts that would raise with Xenomai's tasking >> code. >> >>> Can we safely drop it from all other patches (it's in >>> the context switch fast-path...)? >> No, since prepare_arch_switch() is still applicable. >> >>> Moreover, I bet the >>> ENABLE_INTERRUPTS_HW_COND in entry_32.S' ret_from_fork is related to >>> this as well, right? >> No, it's there to prevent the scheduling tail from running hw IRQs off, >> given that copy_thread() may set a copy for eflags which prevents >> preemption. > > Forget about this one, this does not apply to x86 anymore. So the answer > to this question is rather: that used to be required on x86 a long time > ago due to the implementation of the task switching code in system.h > (2.4 era IIRC); but in any case, yes, this is still required for the > reasons explained above, since we must run the switch code with hw IRQs > off.
Still can't follow: Where is prepare_arch_switch referenced? My dumb approach to do a text search over the ipipe patch and Xenomai failed to find that spot. And then the question: How is disabling the IRQs that task_hijacked reenables? Thanks, Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux _______________________________________________ Adeos-main mailing list [email protected] https://mail.gna.org/listinfo/adeos-main
