From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) by sourceware.org (Postfix) with ESMTPS id 153673858C27 for ; Sun, 25 Apr 2021 16:52:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 153673858C27 Received: by mail-lf1-x12a.google.com with SMTP id 12so84438326lfq.13 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=e6TYuQpy7zW+d2MFzuzoSugNCIWQX0e4VwsdY83jlDqflnLmh8hvA7FUwzd39QXjaX GBw8QRyryleKish9mxDZ0vnnh7Z+z/QlC6XylODIEnhvsjFQTFGrwOetn8iT2IPJOpxh IBYg1d0/QmR+9Gne1ZzUx7qTY2N/TttSsMz39xGS1ThXWsiiTAQSw8uFX2jSGlO7jejY fgGpZ8e65xN16k7FvXgepMd57/hw9+cNmUFR3LYLXIMfdUlbrkj3awsDMPerEFIqj64J 90IHOTehnwI6ldz9umU5KjZFLLldRBff/j4N8/We2+JFoRjeiXLhHpRqXec5/i9BBRx6 fJ0Q== X-Gm-Message-State: AOAM532Hl1czoXP7gouGrEKRRUs5tUuJtfZEO2gV6W/A2Sdbd7WR5XcZ qhiHXQRFkKYcPoNogq5vBUbUXqvYgoxA3eGhFZg= 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.7 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: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha 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.