Re: [Xenomai] BUG: Unhandled exception over domain Xenomai - switching to ROOT

["Jorge Ramirez Ortiz, HCL Europe" <Jorge.Ramirez-Ortiz@hcl.com>]

Please can we go back and reframe the discussion?

But first I'll reiterate: do ignore the marginal issue I had with the framework (I ported and went over 44,785 lines of ANSI-C(kernel/user) and 1995 lines of C++ code  in just a few days -this one was a big pci driver-....I am not really losing my sleep over it) . Besides It is not really relevant to the point I am trying to make and the reason why I am posting here. 

My point is: yes, absolutely, I would expect the framework to allow wakeup calls to linux services from interrupt context. 
Why not? Why is this the wrong expectation to have?
When the client calls the RTDM driver from the wrong context (a non-realtime context in the real-time world), the framework doesn't complain. It handles it and gives the driver the option to chose how it wants to handle it which makes perfect sense to me. 

And anyhow, failing that, I would have expected the real-time driver model to give the user the option to chose the back door context he wants to register to (which is my whole point and what  PREEMPT_RT actually does in the linux domain). And I would expect an rtdm interface for that. So I think my point stands with respect to consistency on the interfaces: either give the client a rtdm_request_irq context flag to request different IRQ contexts or handle wake_up events. 

With respect to your comment about PREEMPT_RT I think it actually helps with what I am trying to articulate here. So I think we are looking at it from different angles.

Anyway I really don't have much more to contribute/say on this matter but as a user, I thought it would be right to spend some time sharing my views since I benefited from this project so many times.

-----Mensaje original-----
De: Jan Kiszka [mailto:jan.kiszka@siemens.com] 
Enviado el: 13 July 2012 12:59
Para: Jorge Ramirez Ortiz, HCL Europe
CC: Philippe Gerum; xenomai@xenomai.org
Asunto: Re: [Xenomai] BUG: Unhandled exception over domain Xenomai - switching to ROOT

[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


::DISCLAIMER::
----------------------------------------------------------------------------------------------------------------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and other defects.

----------------------------------------------------------------------------------------------------------------------------------------------------