From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) by sourceware.org (Postfix) with ESMTPS id 1F67A3858022 for ; Sun, 25 Apr 2021 16:52:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 1F67A3858022 Received: by mail-lf1-x12d.google.com with SMTP id h36so30525090lfv.7 for ; Sun, 25 Apr 2021 09:52:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EB1M0gWo0xUwH/H5pRRZr/jjgjnHFpq4HP5/7TLgquw=; b=JF9mI2y4TdfphGp1v+lnDJ2xGD+nEAgbVlK04bosh6X7XxzCutyzxJTIa+GTzdmizo Y9Qgxk89XloHudV5F+VhreEuGXTIGQTrmrcMIHvEwvzzsgMJzi013E1KfuO4gp0EaCu9 MqMg9cRgSYB1DE6xur1C5vRfnzoDdhbtYdQDvvrT5C57rMS1na4/PZWn/qBF0DvZL8VO pvdzNF8gIVzOEBYTK8rs9kQChfuSFKGnXqyc+ao5Yw5Oo6QN3Pc6vAX4KD7fW3bM/IZV DyTRYcSeqwuGuF5QVZSO4gev2tWIqsPoJ/ST1C/9Bb9kKT5483l2LBmGSKzTdMTWBjHk Mtpg== X-Gm-Message-State: AOAM530HmtaLHXeuGOZTirbadxwGtQaaGxu75VIGegZrhv5k1SehYXpd AaEH0vtfJ8L2QunpL8mWJ8HVmbFEDlAo3m4onHM= X-Google-Smtp-Source: ABdhPJxyKCSLAn2xg/0qj+PERrbhg57bibRrpgyu2+FdeamRpnAVVz+6UeBZD+v1w1V4KlK02GEyZcz75ouK5KpNtEI= X-Received: by 2002:ac2:510d:: with SMTP id q13mr10060117lfb.75.1619369542791; Sun, 25 Apr 2021 09:52:22 -0700 (PDT) MIME-Version: 1.0 References: <20210423230609.13519-1-alx.manpages@gmail.com> <56932c68-4992-c5e4-819f-a88f60b3f63a@gmail.com> In-Reply-To: <56932c68-4992-c5e4-819f-a88f60b3f63a@gmail.com> From: Alexei Starovoitov Date: Sun, 25 Apr 2021 09:52:11 -0700 Message-ID: Subject: Re: [RFC] bpf.2: Use standard types and attributes To: "Alejandro Colomar (man-pages)" Cc: bpf , "Michael Kerrisk (man-pages)" , linux-man , LKML , libc-alpha@sourceware.org, gcc-patches@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, 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: Sun, 25 Apr 2021 16:52:25 -0000 On Sat, Apr 24, 2021 at 10:56 AM Alejandro Colomar (man-pages) wrote: > > Hello Alexei, > > On 4/24/21 1:20 AM, Alexei Starovoitov wrote: > > Nack. > > The man page should describe the kernel api the way it is in .h file. > > Why? Because man page must describe the linux uapi headers the way they are installed in the system and not invent alternative implementations. The users will include those .h with __u32 and will see them in their code. Man page saying something else is a dangerous lie. > using uint32_t in every situation where __u32 is expected. They're both > typedefs for the same basic type. That's irrelevant. Languages like golang have their own bpf.h equivalent that matches /usr/include/linux/bpf.h. > I can understand why Linux will keep using u32 types (and their __ user > space variants), but that doesn't mean user space programs need to use > the same type. No one says that the users must use __u32. See golang example. But if the users do #include they will get them and man page must describe that. > If we have a standard syntax for fixed-width integral types (and for > anything, actually), the manual pages should probably follow it, > whenever possible. Absolutely not. linux man page must describe linux.