Re: [PING] [PATCH] sys/ptrace.h: remove obsolete Linux PTRACE_SEIZE_DEVEL constant

[Zack Weinberg <zackw at panix dot com>]

On Wed, Aug 9, 2017 at 6:39 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 08/08/2017 09:07 PM, Carlos O'Donell wrote:
>> On 08/08/2017 12:30 PM, Dmitry V. Levin wrote:
>>> On Tue, Aug 08, 2017 at 09:20:17AM -0400, Carlos O'Donell wrote:
>>>> On 08/07/2017 11:33 AM, Dmitry V. Levin wrote:
>>>>> Hi,
>>>>>
>>>>> Looks like among those few who care about sys/ptrace.h nobody feels
>>>>> experienced enough to review this change, so I'll go forward and commit it.
>>>>
>>>> Please tread carefully, and give the machine maintainer time to review, or
>>>> directly TO: the machine maintainers and ask for review.
>>>>
>>>> Lack of a response does not mean you can assume consensus. Follow up with
>>>> machine maintainers, even one ACK from a maintainer goes a long way to
>>>> knowing there is support for your change.
>>>
>>> JFYI, PTRACE_SEIZE_DEVEL was an architecture-independent constant.
>>
>> Agreed, but the patch still touches machine-specific headers.
>
> I don't think our maintainer process confers exclusive code ownership,
> quite the opposite actually.  It's unblock-by-default for the
> maintainer, not block-everyone-else.
>
> I looked at Dmitry's changes, and they look good to me.  Please
> reconsider your opposition.

I also think this patch is good (and appropriate for backport to at
least the 2.26 release branch as well), based on the following checks:

- PTRACE_SEIZE_DEVEL appears nowhere in the current Linux kernel
sources, and lxr.free-electrons.com confirms Dmitry's statement that
it was already gone in version 3.4.0.
- The oldest kernel still supported by glibc (version 3.2.0) already
defines PTRACE_SEIZE (with a different numeric value).
- codesearch.debian.net finds no *uses* whatsoever of this identifier.
The only hits are the definitions in glibc's various versions of
sys/ptrace.h, similar sets of definitions in uClibc's sys/ptrace.h and
what appears to be the equivalent of sys/ptrace.h for the Go language,
a thing called "kernel-patch-viewos" that appears to have a complete
copy of kernel 3.1.5 embedded in it, and a program called "criu" that
deemed it necessary to wrap sys/ptrace.h with its own header that
makes sure every last constant from (some version of) linux/ptrace.h
is available, PTRACE_SEIZE_DEVEL included; the definition is the only
appearance of that identifier in that package.

I also observe that the only reason we have architecture-specific
sys/ptrace.h for Linux is that we haven't gotten around to doing the
work required to pull these constants from uapi/{linux,asm}/ptrace.h.
That doesn't look like it would be hard, only tedious.

I don't know Carlos's mind, but it seems likely to me that he didn't
mean to issue a hard NAK, he just wanted the flood of "nobody reacted
to this patch during the freeze so I'm going to take that as assent"
check-ins to slow down.  I'm'a send another message about that.

zw