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. Thanks, Henri. > > -- > Gilles. > _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
