On Wed, 17 Jun 2009, GeunSik Lim wrote:
... You means that we have to utilize wrapper function using sys_sched_setscheduler() function for PID setting of IRQ thread. It's right?
I may be wrong, but from looking through the kernel code, it appears as though sys_sched_setscheduler() is used in places where the target thread could spontaneously dissapear, whereas its non-syscall variant, sched_setscheduler(), is only used when it is clear that the underlying thread can't dissapear, such as during the creation of a new thread. I think that this must be because sys_sched_setscheduler() takes a pid argument, which remains valid even if the underlying thread dissapears, whereas sched_setscheduler() takes a raw task_struct argument, which doesn't provide such guarantees. I don't personally understand why the copy_from_user() call in the do_sched_setscheduler() part of sys_sched_setscheduler() doesn't get upset by being handed an argument from the kernel stack, instead of a user pointer, but as Thomas says, sys_sched_setscheduler() is called from a few places in the kernel, and apparently it works. Note that my attempt to do this from my device-driver didn't work out, because it turns out that irq_to_desc() isn't exported. So my driver can't use this to find the IRQ thread. I'm currently having a quick go at hacking the kernel to provide the set_irq_thread_prio(irq, prio) function that Thomas suggested, but I haven't fiddled with the kernel before. So it remains to be seen whether this works :-). Martin -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
