>
> Then my analysis is correct that you simply missed filtering out the
> si codes that are not signal specific and do not use the fault layout
> in struct siginfo.
> ...
> I would say that you really need a
> white-list of si_codes that whose use of struct siginfo that you know.
> Otherwise you
>
> Then my analysis is correct that you simply missed filtering out the
> si codes that are not signal specific and do not use the fault layout
> in struct siginfo.
> ...
> I would say that you really need a
> white-list of si_codes that whose use of struct siginfo that you know.
> Otherwise you
Martin Pärtel writes:
> And once more in plain text..
>
> On 25 April 2018 at 01:00, Martin Pärtel wrote:
>>
>> Hi all,
>>
>> This was ages ago, but from what I remember...
>>
>>>
>>> Having a second look I really don't understand what
Martin Pärtel writes:
> And once more in plain text..
>
> On 25 April 2018 at 01:00, Martin Pärtel wrote:
>>
>> Hi all,
>>
>> This was ages ago, but from what I remember...
>>
>>>
>>> Having a second look I really don't understand what relay_signal is
>>> trying to do.
>>>
>>> The function
And once more in plain text..
On 25 April 2018 at 01:00, Martin Pärtel wrote:
>
> Hi all,
>
> This was ages ago, but from what I remember...
>
>>
>> Having a second look I really don't understand what relay_signal is
>> trying to do.
>>
>> The function relay_signal does
And once more in plain text..
On 25 April 2018 at 01:00, Martin Pärtel wrote:
>
> Hi all,
>
> This was ages ago, but from what I remember...
>
>>
>> Having a second look I really don't understand what relay_signal is
>> trying to do.
>>
>> The function relay_signal does not pass siginfo through
Sigh I should have Cc'd Martin Partel as well as this bit is his
original code.
Anton Ivanov writes:
> Hi Richard,
>
> There was a post to uml-devel during the days when the sourceforge mailing
> list
> was working in random drop mode which claimed that "this
Sigh I should have Cc'd Martin Partel as well as this bit is his
original code.
Anton Ivanov writes:
> Hi Richard,
>
> There was a post to uml-devel during the days when the sourceforge mailing
> list
> was working in random drop mode which claimed that "this fixes the arm build".
>
> I have
Hi Richard,
There was a post to uml-devel during the days when the sourceforge
mailing list was working in random drop mode which claimed that "this
fixes the arm build".
I have not kept it locally and I do not see it the archive (I do not see
a few other posts there either - including some
Hi Richard,
There was a post to uml-devel during the days when the sourceforge
mailing list was working in random drop mode which claimed that "this
fixes the arm build".
I have not kept it locally and I do not see it the archive (I do not see
a few other posts there either - including some
On Fri, Apr 20, 2018 at 6:06 PM, Anton Ivanov
wrote:
>
> On 04/20/18 15:38, Eric W. Biederman wrote:
>>
>> Today user mode linux only works on x86 and x86_64 and this allows
>> simplifications of relay_signal.
>
>
> I believe someone recently fixed the ARM port. I
On Fri, Apr 20, 2018 at 6:06 PM, Anton Ivanov
wrote:
>
> On 04/20/18 15:38, Eric W. Biederman wrote:
>>
>> Today user mode linux only works on x86 and x86_64 and this allows
>> simplifications of relay_signal.
>
>
> I believe someone recently fixed the ARM port. I have not had the time to
> try
On 04/20/18 15:38, Eric W. Biederman wrote:
Today user mode linux only works on x86 and x86_64 and this allows
simplifications of relay_signal.
I believe someone recently fixed the ARM port. I have not had the time
to try the fixes though.
I have added the new list we are migrating to the
On 04/20/18 15:38, Eric W. Biederman wrote:
Today user mode linux only works on x86 and x86_64 and this allows
simplifications of relay_signal.
I believe someone recently fixed the ARM port. I have not had the time
to try the fixes though.
I have added the new list we are migrating to the
14 matches
Mail list logo