From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 806D9C43462 for ; Tue, 4 May 2021 19:59:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 53B04613B3 for ; Tue, 4 May 2021 19:59:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232650AbhEDUAH (ORCPT ); Tue, 4 May 2021 16:00:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47672 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232615AbhEDUAG (ORCPT ); Tue, 4 May 2021 16:00:06 -0400 Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E98E8C061574; Tue, 4 May 2021 12:59:10 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id v12so10681130wrq.6; Tue, 04 May 2021 12:59:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=DrWNrfi+Ew4LFUqUpxDkLKZY4953siWYFeGLtwXjn7A=; b=QE+7SVJwjgYciwmKm9KJ3PY+qk14muy5KhsoBY6CxPqNYCB/3EW7hITS/9jUc+hNev eC1J6uUPUJ1K8aMJZFPaedCgd0W7KOBvWVOlteC0wcOGz05FFw5VptHLgRvMxfFbWXOn /lqYoLuS7wfqkDhCf71GFCG31oZOgi6OeXkslJCmvYt5PRtc2zA8KRUS+/PNI5vEntjv Ni2YjnYHjt9RZggtvIfXfTm9bnPiQ9VpW/1Q7Bj0UhQd4BJSBC9DdG3FoEiLAK6mG9Ra JxO5nnZ5gH65gA/mtu3gIVC6RCJ1AHsM5+9MiTcOfjku52Rv30TcR42tCOiJ0lTrLBCi 5Clw== 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=DrWNrfi+Ew4LFUqUpxDkLKZY4953siWYFeGLtwXjn7A=; b=oRJYbmItkqxdMFX68NkwEhCJiW5MmdTV3VFoNHgzqa4foIGshnKURjWeTnJ78MxN7N L+DAxHlYNMz0c57hdF26yMyClnurZ1IUlktapi7JdN1EmBQ0IkShcoV1vqIHyPV1Uc34 x+2st6VApjKzazZeUNZlm4e7edeZAR24MdVU/kKIK3tKQQe2a2dI35apqe4q1423Wi3n fvLWTrGDUOKCjlgs9ZWNqu3keoLHM31gx0PrnWvmOzUJKFluIawgHC6rS1xGaEXET9/v aFLhwNiJSEqgi+oDR0ebt1ttdvBs3L/kXwtSOSUU7shbj4BHwFFaEUBEFdtuNEXJmU/5 gEFA== X-Gm-Message-State: AOAM533wCjS/lALEiF8oT6RyB/Vcy0UDy1g5kvJqF2e+nUCUvj+ZpEcE 2nxNZoYve9ZOQOGq/2sRmW0= X-Google-Smtp-Source: ABdhPJx8/T5dui/MKJ9f8IBJbNOXe96bYqrulWjqjgmOC+4G26OcBLa/GwDB3uSESgK9l9w+4GTsZg== X-Received: by 2002:a05:6000:186f:: with SMTP id d15mr33984740wri.400.1620158349706; Tue, 04 May 2021 12:59:09 -0700 (PDT) Received: from [192.168.0.237] ([170.253.36.171]) by smtp.gmail.com with ESMTPSA id x17sm3426158wmc.11.2021.05.04.12.59.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 04 May 2021 12:59:09 -0700 (PDT) Subject: Re: [RFC v2] bpf.2: Use standard types and attributes To: Florian Weimer Cc: Zack Weinberg , Greg KH , Daniel Borkmann , Alexei Starovoitov , "Michael Kerrisk (man-pages)" , linux-man , LKML , glibc , GCC , bpf , Joseph Myers , David Laight 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> <87r1imgu5g.fsf@oldenburg.str.redhat.com> From: "Alejandro Colomar (man-pages)" Message-ID: <0d9a795a-7c6a-3889-af31-2223dc216d15@gmail.com> Date: Tue, 4 May 2021 21:59:06 +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: <87r1imgu5g.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Florian, On 5/4/21 9:45 PM, Florian Weimer wrote: > * Alejandro Colomar: > >> The thing is, in all of those threads, the only reasons to avoid >> types in the kernel (at least, the only explicitly >> mentioned ones) are (a bit simplified, but this is the general idea of >> those threads): >> >> * Possibly breaking something in such a big automated change. >> * Namespace collision with userspace (the C standard allows defining >> uint32_t for nefarious purposes as long as you don't include >> . POSIX prohibits that, though) >> * Uglier > > __u64 can't be formatted with %llu on all architectures. That's not > true for uint64_t, where you have to use %lu on some architectures to > avoid compiler warnings (and technically undefined behavior). There are > preprocessor macros to get the expected format specifiers, but they are > clunky. I don't know if the problem applies to uint32_t. It does > happen with size_t and ptrdiff_t on 32-bit targets (both vary between > int and long). > Hmmm, that's interesting. It looks like Linux always uses long long for 64 bit types, while glibc uses 'long' as long as it's possible, and only uses 'long long' when necessary. Assignment is still 100% valid both ways and binary compatibility also 100% (AFAIK), given they're the same length and signedness, but pointers are incompatible. That's something to note, even though in this case there are no pointers involved, so no incompatibilities. Maybe the kernel and glibc could use the same rules to improve compatibility, but that's out of the scope of this. Thanks, Alex -- Alejandro Colomar Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/ http://www.alejandro-colomar.es/