Hello Steven, > Actually, the handler thread runs _all_ register interrupt handlers. So > there's no way to make one a higher priority than the other. This is a > tough problem. If you have two shared handlers on the same irq line, > and think you can make one a higher priority than the other, you can't. > If the lower one is running (at the lower priority), and it gets > preempted by an RT task with a priority that is between the lower > priority handler and the higher priority handler, the higher priority > handler may never run. The interrupt line for the IRQ is masked while > the handlers are running. So by preempting the lower priority handler > you are also preempting the higher priority IRQ from coming in. > Hmm, I think you did not get my point... What you mention is basic knowledge... ;-)) What I meant was that from Embedded point of view, some developer probably don't care about what the irq-line-number is of some device. But, such a developer probably wants to prioritize the interrupt handler of his device. Dependant on how the hardware layout looks like it can be interrupt # X, Y or Z. If the kernel can match the device name to a certain IRQ #, the implementation is probably much more flexible than by just specifying the IRQ # at the kernel commandline. In the case where the IRQ handler is shared with some other device, than there are 2 options: the developer does not care, or should choose different hardware. Arnaldo mentioned to use the irq-name for this, and to me this sounds good. > > possible to use 1 target image usable on multiple boards with 1 > > single kernel and 1 single config. > > You can still have one kernel and one config. A command line is separate. My mistake: I meant with config the grub, u-boot or ... config, not the kernel config > > five if you count my writing of the chapter in the O'Reilly book > "Building Embedded Linux Systems" about RT. But these are some of the Interesting... When will this book be finished? I am always curious about the point of view of others on RT... (I am working with Ingo's RT-patch for several years now, started with the early preemption patches on 2.4 kernels) 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
