lkml.org 
[lkml]   [2014]   [Jul]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/2] alpha: Remove "strange" OSF/1 fork semantics
On 07/30/2014 12:04 PM, Måns Rullgård wrote:
> Richard Henderson <rth@twiddle.net> writes:
>
>> The assignment to regs->r20 kills the original tls_val input
>> to the clone syscall, which means that clone can no longer be
>> restarted with the original inputs.
>>
>> We could, perhaps, retain this result for true fork, but OSF/1
>> compatibility is no longer important. Note that glibc has never
>> used the r20 result value, instead always testing r0 vs 0 to
>> determine the child/parent status.
>
> What effect does this have on OSF/1 compat?

I don't know, as I've never had access to osf/1 myself. It depends on how that
$20 value is used -- potentially, fork(3) no longer works.

I can imagine that we could retain these assignments under the condition of
clone_flags == 0, which both implies a basic fork as well as the fact that the
tls_val argument is unused.

But I do have to ask first if anyone actually cares. Surely the amount of
osf-on-linux emulation is a vanishingly small proportion of the already small
alpha-linux population.


r~
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2014-07-31 01:41    [W:0.071 / U:0.332 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site