On Tue, Jul 20, 2021 at 3:56 PM Philippe Gerum wrote:
> > But maybe it can offer enough to implement signal delivery for exceptions?
> >
> > The signal approach also allows us to use the very same signal
> > handlers in userspace
> > for realtime as provided by Xenomai and PREEMPT_RT.
>
> You
Philippe Gerum writes:
> Richard Weinberger via Xenomai writes:
>
>> On Tue, Jul 20, 2021 at 12:53 PM Jan Kiszka wrote:
>>> > I've heard that with dovetail Xenomai no longer sees exceptions.
>>> > So this is a set in stone concept?
>>>
>>> Xenomai can no longer declare exceptions resolved.
Richard Weinberger via Xenomai writes:
> On Tue, Jul 20, 2021 at 12:53 PM Jan Kiszka wrote:
>> > I've heard that with dovetail Xenomai no longer sees exceptions.
>> > So this is a set in stone concept?
>>
>> Xenomai can no longer declare exceptions resolved. It still sees them.
>
>
On Tue, Jul 20, 2021 at 12:53 PM Jan Kiszka wrote:
> > I've heard that with dovetail Xenomai no longer sees exceptions.
> > So this is a set in stone concept?
>
> Xenomai can no longer declare exceptions resolved. It still sees them.
Understood.
> If we come up with a reasonable use case, I
On 20.07.21 11:33, Richard Weinberger wrote:
> On Tue, Jul 20, 2021 at 11:27 AM Jan Kiszka wrote:
>> Then look at dovetail - ipipe will vanish. I'm pretty sure now your
>> approach faces the same issue like we do /wrt not delivering fixed-up
>> faults.
>>
>> If that is the case, we should first
On Tue, Jul 20, 2021 at 11:27 AM Jan Kiszka wrote:
> Then look at dovetail - ipipe will vanish. I'm pretty sure now your
> approach faces the same issue like we do /wrt not delivering fixed-up
> faults.
>
> If that is the case, we should first of all ensure that the foundation
> is provided by
On 20.07.21 09:57, Richard Weinberger wrote:
> On Mon, Jul 19, 2021 at 4:42 PM Jan Kiszka wrote:
>> We have kind of a similar case in our backlog. The application expects
>> to handle certain FPU-related faults gracefully, i.e. without falling
>> out of RT with the causing thread, using a context
On Mon, Jul 19, 2021 at 4:42 PM Jan Kiszka wrote:
> We have kind of a similar case in our backlog. The application expects
> to handle certain FPU-related faults gracefully, i.e. without falling
> out of RT with the causing thread, using a context update to bring it on
> the road again.
>
> We
On 19.07.21 12:08, Richard Weinberger wrote:
> On Thu, Jul 8, 2021 at 10:48 PM Jan Kiszka via Xenomai
> wrote:
>> The model chosen for this is dedicating a real-time thread to this task.
>> This has the advantage of isolating the thread a bit from the debugged
>> contexts and also avoids having
On Thu, Jul 8, 2021 at 10:48 PM Jan Kiszka via Xenomai
wrote:
> The model chosen for this is dedicating a real-time thread to this task.
> This has the advantage of isolating the thread a bit from the debugged
> contexts and also avoids having to introduce any kind of asynchronous
> signaling
On 08.07.21 22:47, Jan Kiszka via Xenomai wrote:
> Changes in v2:
> - use 'bool' in patch 1
> - reserve y2038 syscall range before adding new ones in patch 2
> - ignore SIG32 (cancellation) in patch 3 to avoid failing tests
>
> This allows debugged real-time processes to execute crucial
Changes in v2:
- use 'bool' in patch 1
- reserve y2038 syscall range before adding new ones in patch 2
- ignore SIG32 (cancellation) in patch 3 to avoid failing tests
This allows debugged real-time processes to execute crucial operations
right before and after being stopped by a debugger. Such
12 matches
Mail list logo
