On Wed, 17 Jun 2009, Remy Bohmer wrote: > 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. It _is_ solely a user space issue. The kernel has absolutely no idea what a system is used for and what the system designer decides is the best priority balance. The kernel provides a default value which just works for bootup. We want drivers and the kernel to be as generic as possible to avoid tons of extra special cases in the code which are no benefit at all. > 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? Can we talk about real world issues please ? > Or some kernel developer change the name of the interrupt handler? All > different implementations in userspace has to follow as well... And As I said already, we need to expose the tid of the irq thread to sysfs as we do with the irq number right now. > why is 50 the right default to use, and not 30 or 60? 50 is a default startup value and the driver does not know in which device it is built in. It does not care at all whether the device is a radio a screwdriver or a blinkenlight. > For a realtime embedded device this could all be the case, and it is > not that strange. There is no such thing "realtime embedded device". There is a device which requires a real time kernel. Again the kernel does not care about the overall system requirements. This can only be decided by the system designer and the system designer has to do the same work for the user space as well. It's all about policies and the kernel does not implement policies except some safety ones. The kernel provides selinux as well and the system designer/admin decides which policies to use. > 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) You can post it and I'm not going to take it for the above reasons. Thanks, tglx -- 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
