Re: [PATCH 1/2] alpha: Remove "strange" OSF/1 fork semantics

[Måns Rullgård]

Richard Henderson <rth@xxxxxxxxxxx> writes:

> On 07/30/2014 12:04 PM, Måns Rullgård wrote:
>> Richard Henderson <rth@xxxxxxxxxxx> 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.

That would render the entire OSF/1 compat useless.

> 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.

I don't like the idea of breaking features without good reason.  It's
also not obvious to me that those who have reasons to run Alpha hardware
at all also don't have reasons to run OSF/1 binaries on it.

I have Alpha machines with both Linux and OSF/1 (Tru64), so I could run
some quick tests, though I'm not certain what would make a good test
case for this.

-- 
Måns Rullgård
mans@xxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html