From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from www62.your-server.de (www62.your-server.de [213.133.104.62]) by sourceware.org (Postfix) with ESMTPS id 740F73949094 for ; Tue, 4 May 2021 16:08:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 740F73949094 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=iogearbox.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=daniel@iogearbox.net Received: from sslproxy03.your-server.de ([88.198.220.132]) by www62.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1ldxbT-0002Ox-16; Tue, 04 May 2021 18:08:55 +0200 Received: from [85.7.101.30] (helo=linux.home) by sslproxy03.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ldxbS-0007mn-Pg; Tue, 04 May 2021 18:08:54 +0200 Subject: Re: [RFC v2] bpf.2: Use standard types and attributes To: "Alejandro Colomar (man-pages)" , Greg KH , Alexei Starovoitov Cc: "Michael Kerrisk (man-pages)" , linux-man , LKML , glibc , GCC , bpf , David Laight , Zack Weinberg , Joseph Myers References: <20210423230609.13519-1-alx.manpages@gmail.com> <20210504110519.16097-1-alx.manpages@gmail.com> <69fb22e0-84bd-47fb-35b5-537a7d39c692@gmail.com> From: Daniel Borkmann Message-ID: Date: Tue, 4 May 2021 18:08:54 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <69fb22e0-84bd-47fb-35b5-537a7d39c692@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Authenticated-Sender: daniel@iogearbox.net X-Virus-Scanned: Clear (ClamAV 0.103.2/26160/Tue May 4 13:06:49 2021) X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2021 16:09:08 -0000 On 5/4/21 5:53 PM, Alejandro Colomar (man-pages) wrote: > Hi Greg and Alexei, > >> On Tue, May 04, 2021 at 07:12:01AM -0700, Alexei Starovoitov wrote: >>> For the same reasons as explained earlier: >>> Nacked-by: Alexei Starovoitov > > Okay, I'll add that. > > On 5/4/21 4:24 PM, Greg KH wrote:> I agree, the two are not the same type at all, this change should not be >> accepted. > > I get that in the kernel you don't use the standard fixed-width types (with some exceptions), probably not to mess with code that relies on not being included (I hope there's not much code that relies on this in 2021, but who knows). > > But, there is zero difference between these types, from the point of view of the compiler.  There's 100% compatibility between those types, and you're able to mix'n'match them.  See some example below. > > Could you please explain why the documentation, which supposedly only documents the API and not the internal implementation, should not use standard naming conventions?  The standard is much easier to read for userspace programmers, which might ignore why the kernel does some things in some specific ways. > > BTW, just to clarify, bpf.2 is just a small sample to get reviews; the original intention was to replace __uNN by uintNN_t in all of the manual pages. But what /problem/ is this really solving? Why bother to change this /now/ after so many years?! I think this is causing more confusion than solving anything, really. Moreover, what are you doing with all the __{le,be}{16,32,64} types in uapi? Anyway, NAK for bpf.2 specifically, and the idea generally.. Best, Daniel