Henri Roosen wrote:
> Ok, I'm back on this one now.
>
> I couldn't find the 'the signal rebase over the mayday support'
> patches which Philippe mentioned. I searched the xenomai-2.5 and
> xenomai-head trees. Is it somewhere available? It might be a good
> starting point.
When Philippe said: "So you need the signal rebase over the mayday
support I merged a few months ago.". The "I merged a few months ago" was
referring to the mayday support, not the signal rebase. This signal
rebase does not exist. Because, especially due to FPU handling, it is
not a trivial thing to do. sigcontext makes things even more complicated.
>
> The way I see it, currently available is an implementation like used
> in sigtest. This means using a special skin that gets a handler
> installed for signals at xeno_bind_skin(..., handler). Current status
> seems to me a framework for supporting kill system calls. As far as I
> can see the signal reporting part has no support for sigcontext (which
> is a requirement for us). Also there is no connection of events like
> SIGFPE to this mechanism.
The current framework allows:
- sending a signal to a thread
- getting the handler executed by the thread.
But, nothing sends signals to a thread, and nothings allows registering
handlers for handling different signals.
What the mayday support would changes is the way a signal handler could
get executed by a thread.
>
> Where I see the mayday implementation comes in use is when sending
> signals to other threads: it forces the target thread to make a kernel
> call from userspace. Then the handle_rt_signals() function can handle
> the pending signals.
> Is the mayday implementation also needed for exception signals
> (SIGFPE), which are generated by the task itself? I see the current
> implementation needs a system call from userspace to provide the
> struct xnsigs to kernel space. So I guess answer to the last question
> is yes... but that might also have some overhead as we were in kernel
> space already..
No real overhead. Since we are in kernel-space, the signal handler will
get executed when going back to user-space. The exception causes a
switch to kernel-space anyway.
>
> Is it a good idea to implement SIGFPE support using the signal-skin?
I think it is a better idea to implement this with whatever skin you are
using native, posix, etc...
>
> So for me there are some unclarities of how to implement primary
> domain exception handling from userspace. Would be good when this
> email triggers a discussion of how to correctly implement it so I can
> then make a useful contribution to the project.
>
> Thanks,
> Henri.
>
--
Gilles.
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
