From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4DA84917.1000400@domain.hid> Date: Fri, 15 Apr 2011 15:33:11 +0200 From: Gilles Chanteperdrix MIME-Version: 1.0 References: <4D5039AD.2070205@domain.hid> <4D50433D.1040804@domain.hid> <1297154320.2023.6.camel@domain.hid> <1297156556.2023.9.camel@domain.hid> <4D513278.4090606@domain.hid> <1297167172.2023.11.camel@domain.hid> <4D513427.6050707@domain.hid> <1297167750.2023.13.camel@domain.hid> <4D5137B0.8050006@domain.hid> <1297169771.2023.15.camel@domain.hid> <4D514109.9060103@domain.hid> <1297171546.2023.19.camel@domain.hid> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] Exception handlers in primary domain / user-space signals List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Henri Roosen Cc: xenomai@xenomai.org 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.