Philippe Gerum wrote:
> 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.
All this is certainly doable, but even without Xenomai, going to
kernel-space in case of exception then building a signal frame, going
back to user-space, executing the signal handler, then returning from
the signal (possibly going to kernel-space again) is not exactly a light
operation. So, surely, exceptions should remain exceptional and using
them routinely does not look like the right thing to do.
For the signals themselve:
- implementing SIGFPE will require clearing up exceptions at the FPU
level, which may not be easy, depending on the architecture;
- what will you do with SIGTRAP, stop the task? Why would you need to
remain in primary mode?
- why do you get a SIGILL on ARM? This is an abnormal condition...
--
Gilles.
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
