On 07/30/2014 12:04 PM, Måns Rullgård wrote: > Richard Henderson <r...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
