Hello Thomas, >> > The right way is to do this change from userspace. >> What a nonsense. Care to look at the code ? >> The irq/softirq threads call sys_sched_setscheduler() already to >> change their priorities. > More awake, it should be changed for correctness sake. :) >> The right way to do this is to have an interface >> set_irq_thread_prio(irq, prio) > This still stands, if we need a way to change the prio from the > driver. > But the more I think about it should be done from user space. Some time ago we discussed on lkml this same subject. I made several patches for it back then, but due to change of focus I somewhat forgot these patches... First post: http://www.nabble.com/-patch-0-3--add-kernel-cmdline-support-for-interrupt-thread-priorities-(repost:CC-to-LKML)-td14424269.html I posted them recently again forward ported to 2.6.26: http://www.spinics.net/lists/linux-rt-users/msg04237.html I do not agree that it is a userspace issue, the rationale behind this is that users care about functionality, not specific interrupt thread ids. Thread-ids can/will vary, and a lot of scripting is needed to map the proper interrupt handler of the right device driver to the proper kernel thread, and to set the priorities accordingly. And what if there is not a userland at all? and init is the only process in the system, or there is no shell installed? Or some kernel developer change the name of the interrupt handler? All different implementations in userspace has to follow as well... And why is 50 the right default to use, and not 30 or 60? For a realtime embedded device this could all be the case, and it is not that strange. This was for me the reasoning back then to provide patches that do it from inside the kernel. The patches provide a means by configuring it via the kernel commandline, or Kconfig. The configuration is based on the name provided by the interrupt handler name provided by request_irq(). If the irq-thread is created it is looked up inside a map what the priority of the IRQ-thread needs to be. The IRQ-thread is created with the required prio. It also checks if the IRQ is shared, and it checks if there are conflicts as well. If there is interest I can rework this and make it mainline ready on the short term for mainline 2.6.29-RT. (in that case comments are very welcome on the 2.6.26 edition, see above) Kind Regards, Remy -- 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
