From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) by sourceware.org (Postfix) with ESMTPS id 9DDD3384841A for ; Tue, 4 May 2021 20:16:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 9DDD3384841A Received: by mail-wr1-x42e.google.com with SMTP id a4so10755175wrr.2 for ; Tue, 04 May 2021 13:16:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Op37xX+0qr4bnMuSBrGHW+sAMoQGBPFehE3Xd/Y0kxY=; b=a0P7Z7fiWkbC53a+wrhTBB/bu98jlVNCsFMoLrR1NnYMb7qqrnHcL1Dvyvfxc7UGkZ +GnsJTbF0MoiL071cKJ2JqeP1k6lNT5KYmmqLACg86NQ2GCgPfG5kQIHHuRYxp1ov/Ce f7//X6002t8BvhgfshvEVAnNYK+KE5RPWp0OFLRHW1zqeI5cL2g1DewRpSTYtzr3wNax t7NpEiFmVv0uzFY4Om9UazDTKtpyJX2RM6WO5csLlzuIrZDi2XXkc6vwOiAWKww5N/VM n/PLeI3cVAo2wxDocFAF6plkTcGC5VBXxOXY1NiYerIvMMLij+FrzKtaaqIax07gTBLq FJ7A== X-Gm-Message-State: AOAM533exXsAKuYlSOrDBA4/eDpFJSIgKVjFt0EgmeqwtZ1ps0YhszDx J5LzV8rWX4PG01eyiYFxQvU= X-Google-Smtp-Source: ABdhPJzjo2nvwoKSLuOCYKx7qg/CdUVtVfCTMxkqk1rM/AbzglelIjJNIGtqsictc0r8+I64cOQu0Q== X-Received: by 2002:a5d:4b46:: with SMTP id w6mr34194176wrs.5.1620159384629; Tue, 04 May 2021 13:16:24 -0700 (PDT) Received: from [192.168.0.237] ([170.253.36.171]) by smtp.gmail.com with ESMTPSA id i11sm17133658wrp.56.2021.05.04.13.16.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 04 May 2021 13:16:24 -0700 (PDT) Subject: Re: [RFC v2] bpf.2: Use standard types and attributes To: Daniel Borkmann , Zack Weinberg , Greg KH Cc: Alexei Starovoitov , "Michael Kerrisk (man-pages)" , linux-man , LKML , glibc , GCC , bpf , Joseph Myers , David Laight , davem@davemloft.net References: <20210423230609.13519-1-alx.manpages@gmail.com> <20210504110519.16097-1-alx.manpages@gmail.com> <69fb22e0-84bd-47fb-35b5-537a7d39c692@gmail.com> <6740a229-842e-b368-86eb-defc786b3658@gmail.com> <8a184afe-14b7-ed15-eb6a-960ea05251d1@iogearbox.net> From: "Alejandro Colomar (man-pages)" Message-ID: <6ad5b5e3-1f9b-2302-84e5-8141d95fc142@gmail.com> Date: Tue, 4 May 2021 22:16:22 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <8a184afe-14b7-ed15-eb6a-960ea05251d1@iogearbox.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham 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 20:16:27 -0000 Hi Daniel, On 5/4/21 10:06 PM, Daniel Borkmann wrote: >> >> On 5/4/21 6:08 PM, Daniel Borkmann wrote: >>  > >>  > 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.. >> >> I'm trying to clarify the manual pages as much as possible, by using >> standard conventions and similar structure all around the pages.  Not >> everyone understands kernel conventions.  Basically, Zack said very >> much what I had in mind with this patch. > > But then are you also converting, for example, __{le,be}{16,32,64} to plain > uint{16,32,64}_t in the man pages and thus removing contextual information > (or inventing new equivalent types)? > > What about other types exposed to user space like __sum16, __wsum, or > __poll_t > when they are part of a man page, etc? Sorry, I forgot to address that part in my answer. If there's no standard way of naming a type without losing information, we can use the kernel naming. I have no objection to that. These are the only pages that seem to be using those: $ grep -Enr '\b__[a-z][a-z]+[0-9]+' man? man2/clone.2:44:clone, __clone2, clone3 \- create a child process man2/clone.2:1694:.BI "int __clone2(int (*" "fn" ")(void *)," man2/clone.2:1717:.BR __clone2 () man7/sock_diag.7:362: __be16 idiag_sport; man7/sock_diag.7:363: __be16 idiag_dport; man7/sock_diag.7:364: __be32 idiag_src[4]; man7/sock_diag.7:365: __be32 idiag_dst[4]; man7/bpf-helpers.7:514:.B \fBlong bpf_skb_vlan_push(struct sk_buff *\fP\fIskb\fP\fB, __be16\fP \fIvlan_proto\fP\fB, u16\fP \fIvlan_tci\fP\fB)\fP man7/bpf-helpers.7:878:.B \fBs64 bpf_csum_diff(__be32 *\fP\fIfrom\fP\fB, u32\fP \fIfrom_size\fP\fB, __be32 *\fP\fIto\fP\fB, u32\fP \fIto_size\fP\fB, __wsum\fP \fIseed\fP\fB)\fP man7/bpf-helpers.7:949:.B \fBlong bpf_skb_change_proto(struct sk_buff *\fP\fIskb\fP\fB, __be16\fP \fIproto\fP\fB, u64\fP \fIflags\fP\fB)\fP man7/system_data_types.7:473:.I __int128 man7/system_data_types.7:475:.I __int128 man7/system_data_types.7:1584:.I unsigned __int128 man7/system_data_types.7:1586:.I unsigned __int128 $ So sock_diag.7 and bpf-helpers.7 and only a handful of cases. Not much of a problem. I'd keep those untouched. Regards, Alex -- Alejandro Colomar Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/ http://www.alejandro-colomar.es/