Philippe Gerum wrote:
> On Tue, 2011-02-08 at 13:09 +0100, Gilles Chanteperdrix wrote:
>> 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.
>
> No, you missed the point. The idea is not to forge a stack frame in
> kernel space. The idea is to propagate enough information to userland in
> order to provide whatever bits are needed there.
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.
--
Gilles.
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
