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