[please don't top-post] On 2012-07-13 13:24, Jorge Ramirez Ortiz, HCL Europe wrote: > Yes it does: the caller ignores upfront whether the call will be handled in > realtime or non-realtime context by the driver. > The client (of course!) can/should (it doesn't really matter for the sake of > the argument) take the adequate measures to make sure it will get into the > adequate path. > But the _interface_ does not guarantee which path it will take. This is a > fact that you can't disagree with. > > But please allow me to re-frame the discussion: I am not discussing here > about realtime design practises or about how to use the framework properly. > I am merely commenting on the _interfaces_ to the realtime framework and > their consistency.
As far as I understood, you were using interfaces outside of the scope of the RTDM framework. Sorry, we can change the Linux kernel to gracefully handle all types of improper RT designs. We already have quite some infrastructure to detect such scenarios, and if there are holes, we are happy for suggestions (bug reports, patches etc.) to plug them. But, e.g., failing a call like wake_up from wrong contexts is impractical (there are too many spots to patch). Or what is your expectation? BTW, if you call wake_up under PREEMPT-RT from a hard IRQ handler, you will get similar results: at best lockdep will bark at you, at worst your box locks up hard. Different architecture, similar problem. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux _______________________________________________ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
