Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp5094455ybi; Sat, 20 Jul 2019 12:35:23 -0700 (PDT) X-Google-Smtp-Source: APXvYqxosXo1ogIr+1n+3+8HKtkxWUBhU98iD12Ga4Ob97FGjcfRS+upiCFCBuaUN3tgz58+6FnM X-Received: by 2002:a17:902:bf09:: with SMTP id bi9mr60610342plb.143.1563651323708; Sat, 20 Jul 2019 12:35:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1563651323; cv=none; d=google.com; s=arc-20160816; b=eLNVBqywz1jHShrGwCVvYwpdd+fQGBIWnzymJYoOq1gWopzTJNG9fTWmiqnXZLx/Gp rWUao7Z46C7EPCWIZf0SMDxKKZKDyfQVAx9bLhS93EEs8O242cExHbO51KQoC+m/EafE hCY7jNBaubLHbvnpWfhV1NgieufXljlnhqTOreeIwAkslvnqZ3bqFK+qeIxF5QcyOM3R RktMBAmNvx2ELducf7QHyKC9Aepf4lfQqV0AOxB2RjZCft+GX/EHP03jQ4ai85/FHyPD jnEGtNXls5GE6tgRwa+w3GJCxESDYsOfSj4YCe/8KVq0787OzxHoCXFou3+su3eP7aZs KH0A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:in-reply-to:date :references:subject:cc:to:from; bh=ehlJFzPYon9MHJwQbcuVUpDrefE84teYtNOpyEdIPG8=; b=BYEG2b0UHT59v3SF91lPI4nfa6LMXABsLbs/fBoaR6t1FK9M6MXtCRh4vi4bRDAmWK 71ef02Xad5T6X2wjfu28gYNMnou1bQIn1HyZp3zYlzHzmqPo85JCava3IMpIjjeeZ9I0 rLOVu8ci+5fUhNTz3HApKg4LEJl99WqA8PGvccxuiLrcQURXfzgTaDtF34Xv24tWFaYY 7NO07jf17cfPdZBR1cP0YJORSZ4wXbQvuNo9C6y6idYWGbQ9eQRO645tH4n6xaU/o1cl /TnbFZ/bPNj1ApoVKngc5vLUe4FQh2GmjLXjhE482270EjavRP/LuRsc0s1IMp4gZ79F zilg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o1si3596747plb.337.2019.07.20.12.35.06; Sat, 20 Jul 2019 12:35:23 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726186AbfGTTet (ORCPT + 99 others); Sat, 20 Jul 2019 15:34:49 -0400 Received: from albireo.enyo.de ([5.158.152.32]:37712 "EHLO albireo.enyo.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725940AbfGTTes (ORCPT ); Sat, 20 Jul 2019 15:34:48 -0400 Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1hov80-0005v7-Fe; Sat, 20 Jul 2019 19:34:44 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.92) (envelope-from ) id 1hov80-0004M4-AR; Sat, 20 Jul 2019 21:34:44 +0200 From: Florian Weimer To: Arnd Bergmann Cc: Sergei Trofimovich , Networking , Linux Kernel Mailing List , GNU C Library , "David S. Miller" , Michael Kerrisk , linux-man Subject: Re: linux-headers-5.2 and proper use of SIOCGSTAMP References: <20190720174844.4b989d34@sf> <87wogca86l.fsf@mid.deneb.enyo.de> Date: Sat, 20 Jul 2019 21:34:44 +0200 In-Reply-To: (Arnd Bergmann's message of "Sat, 20 Jul 2019 20:50:23 +0200") Message-ID: <87muh8a4a3.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Arnd Bergmann: > On Sat, Jul 20, 2019 at 8:10 PM Florian Weimer wrote: >> >> * Sergei Trofimovich: >> >> > Should #include always be included by user app? >> > Or should glibc tweak it's definition of '#include ' >> > to make it available on both old and new version of linux headers? >> >> What is the reason for dropping SIOCGSTAMP from ? >> >> If we know that, it will be much easier to decide what to do about >> . > > As far as I can tell, nobody thought it would be a problem to move it > from asm/sockios.h to linux/sockios.h, as the general rule is that one > should use the linux/*.h version if both exist, and that the asm/*.h > version only contains architecture specific definitions. The new > definition is the same across all architectures, so it made sense to > have it in the common file. Most of the socket-related constants are not exposed in UAPI headers, although userspace is expected to use them. It seems to me that due to the lack of other options among the UAPI headers, has been a dumping ground for various socket-related things in the past, whether actually architecture-specific or not. does not include , so that's why we usually end up with including (perhaps indirectly via ), which used to include on most (all?) architectures. That in turn provided some of the SIOC* constants in the past, so people didn't investigate other options. I think we can change glibc to include in addition to . looks reasonably clean to me, much better than . I'm still working on the other breakage, and I'm severely limited by the machine resources I have access to.