On Tue, Feb 8, 2011 at 2:25 PM, Philippe Gerum <[email protected]> wrote: > On Tue, 2011-02-08 at 14:11 +0100, Gilles Chanteperdrix wrote: >> Philippe Gerum wrote: >> > On Tue, 2011-02-08 at 13:51 +0100, Henri Roosen wrote: >> >> On Tue, Feb 8, 2011 at 1:31 PM, Gilles Chanteperdrix >> >> <[email protected]> wrote: >> >>> Philippe Gerum wrote: >> >>>> On Tue, 2011-02-08 at 13:16 +0100, Gilles Chanteperdrix wrote: >> >>>>> I was not talking about the Xenomai case specifically, but since Henri >> >>>>> would like to have the full signals implementation with Xenomai, this >> >>>>> does a apply to Xenomai too. >> >>>>> >> >>>>> >> >>>> I think we all agree that having a complete signal implementation for >> >>>> Xenomai in pure rt mode won't happen overnight. So the point is now: how >> >>>> could it be mimicked, at least for the most useful part. >> >>>> >> >>> My point is that whatever you do, a switch user-kernel, then kernel-user >> >>> is not going to be lightweight, so avoiding it in the application in the >> >>> first place may be a better idea. >> >>> >> >>> My aim with implementing complete signals was rather for things like >> >>> timer_* and mq_notify, where the interface requires them, I did not even >> >>> imagine implementing SIGFPE, SIGILL, SIGTRAP, which I thought could not >> >>> be time critical anyway, for the reasons explained earlier. So, my >> >>> question (rather to Henri) is: what would we need SIGFPE, SIGILL, >> >>> SIGTRAP in an real-time application for? >> >> I agree it might be unusual. For the tracing use case: the SIGTRAP we >> >> use as a means for tracing whether code is actually executed, just >> >> like breakpoints, we exchange the code to 0xcc and handle the >> >> exceptions do book-keeping but don't stop the task. We know this has >> >> overhead, it also had when using our old OS. The old OS handled it in >> >> an accepted amount of time. Using the Xenomai kernel it also works, >> >> however the overhead is not acceptable anymore. >> >> Installing a floating point exception handler was also provided to our >> >> customers with the old OS and we have to make that available now too. >> >> So actually it is all because of legacy reasons, we have to provide >> >> similar functionality as with the old OS. >> >> >> >> I'm afraid we cannot mimic enough so it suits our use cases. We need >> >> the fault context to handle the exception and to set the IP one >> >> instruction back. >> > >> > So you need the signal rebase over the mayday support I merged a few >> > months ago. Back to square one I'm afraid, this won't be available soon, >> > albeit this might happen in the 2.6 timeframe. We'll see. >> >> Well, not necessarily, the fault handler may set the IP, suspend the >> task, wake-up the dedicated fault-handler thread, then, the dedicated >> fault-handler may wake-up the suspended task when the work has been done. >> > > This is not exactly what I'd call a straightforward solution (which was > the point of offloading the work to userland) . If one knows how to do > that within the Xenomai core, he could just re-route the mayday > mechanism, no need for sideways. >
Unfortunately are facing some other problems we need to work on first. But I would like to investigate the fault handling over the mayday mechanism when I find some spare time. Could you point me to the 'signal rebase over the mayday' patches? I can find them in the xenomai-head branch, right? > -- > Philippe. > > > _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
