On Tue, 2011-02-08 at 10:10 +0100, Henri Roosen wrote: > On Tue, Feb 8, 2011 at 9:38 AM, Philippe Gerum <[email protected]> wrote: > > On Tue, 2011-02-08 at 09:21 +0100, Henri Roosen wrote: > >> On Mon, Feb 7, 2011 at 8:08 PM, Gilles Chanteperdrix > >> <[email protected]> wrote: > >> > Henri Roosen wrote: > >> >> On Mon, Feb 7, 2011 at 7:27 PM, Gilles Chanteperdrix > >> >> <[email protected]> wrote: > >> >>> Henri Roosen wrote: > >> >>>> We are using signal handlers for catching exceptions which our > >> >>>> application is allowed to make and which we know how to handle. > >> >>>> > >> >>>> The current Xenomai implementation is to switch to the secondary > >> >>>> domain and call the handlers from there. > >> >>>> Unfortunately this takes too much time for our application and we > >> >>>> would like to handle the exception without the switch to the secondary > >> >>>> domain, in primary domain. > >> >>>> > >> >>>> Can anyone give some advice how to implement that? > >> >>>> Will "user-space signals" which was planned for Xenomai 2.6 fulfill > >> >>>> this need? > >> >>>> Is there already code available for user-space signals? > >> >>> In the 2.5 series, we added some code to support signals. The signals > >> >>> are multiplexed per-skin in kernel-space, and demultiplexed in > >> >>> user-space, upon exit of system calls. We implemented a unit test of > >> >>> this functionality with the "sigtest" skin and user-space test, but > >> >>> they > >> >>> only work upon return from system calls. > >> >>> > >> >>> Then we added support for the "mayday" page, which made us realize, > >> >>> that > >> >>> maybe implementing signals handling at any time, not only when > >> >>> returning > >> >>> from system calls, was possible. But then came the realization that in > >> >>> order to implement that, we would have to fiddle with the FPU, which is > >> >>> an area where we have a certain tradition for not getting the things > >> >>> right at the first attempt. So, we kind of stopped here. > >> >>> > >> >>> So, if you want some ad-hoc signals upon return from system call, the > >> >>> task is pretty easy. If you want the full posix signals interface, then > >> >>> things are going to be a bit harder. > >> >>> > >> >> I am afraid it's going to be a bit harder; we would need it when the > >> >> exception occurs and that is in most cases not at a place in the code > >> >> where there is a system call :-(. > >> > > >> > What kind of exception is it? Could not the exception be signalled at > >> > the next system call? > >> > >> Our customers provide the application code, we provide more or less > >> the framework. Customers can install exception handlers for for > >> instance floating point exceptions (SIGFPE). > >> Besides that we provide a means of tracing the application code, which > >> is handled by breakpoints in the code which then does some bookkeeping > >> and lets the task run again. Of course that has some overhead also > >> when using our old OS, but Linux-Xenomai has so much overhead because > >> of the secondary domain switch. Therefore we would like to handle it > >> in primary domain. > > > > Connect a high priority shadow task in userland to an exception handler > > installed in kernel space via some synchronization (semaphore, event, > > whatever). The handler would be called upon exception, then would wake > > up your task in userland, which would preempt immediately any other task > > activity due to its higher priority. This would not entail any mode > > switch, only a fast context switch between Xenomai contexts. > > > > Over this "exception server" task context, you should be able to execute > > any kind of user-space handler to mimic the POSIX signal interface as > > much as required. Of course this would not run over the faulting context > > like POSIX signals do (unless SIGEV_THREAD is used), but this might be > > ok for your purpose. > > > > Unfortunately we do need the faulting context for the SIGFPE signal > and SIGTRAP (x86) / SIGILL (arm) signals...
It's too much to ask in the current implementation. There is no quick fix to this, I mean if you want to have a standard signal frame to exploit in userland. Otherwise, you could pull some relevant bits from the exception frame in kernel space (you have the struct pt_regs of the faulting context avail there), and pass them through your synchronization mechanism to userland, so as to fake some kind of pseudo-signal frame. > > For some quick tests, where in Xenomai code would be best to place a > hook for catching exceptions in primary domain which would also > provide the faulting context? Would that be xnpod_trap_fault? > Yes. > >> > >> > > >> >> > >> >> I was thinking of adding a hook in Xenomai's exception handler before > >> >> it makes the switch to the secondary domain... but that would of > >> >> course be a very ugly hack and I don't know if it can be done. Do you > >> >> have a suggestion? > >> >> > >> >> What are the plans with the full posix signals interface? > >> > > >> > Plans were to get it during the 2.6 branch, but of course if someone is > >> > able to contribute it before, there is no problem. > >> > >> I would like to help out of course, but first would like some quick > >> tests if it would be feasible in our application. Any hints on that? > >> > >> Thanks, > >> Henri. > >> > >> > > >> >> > >> >> Thanks, > >> >>> -- > >> >>> Gilles. > >> >>> > >> >> > >> > > >> > > >> > -- > >> > Gilles. > >> > > >> > >> _______________________________________________ > >> Xenomai-help mailing list > >> [email protected] > >> https://mail.gna.org/listinfo/xenomai-help > > > > -- > > Philippe. > > > > > > -- Philippe. _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
