From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) by sourceware.org (Postfix) with ESMTPS id 6FA63385841A for ; Thu, 25 Aug 2022 00:57:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6FA63385841A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linuxfoundation.org Received: by mail-ed1-x531.google.com with SMTP id r4so24143785edi.8 for ; Wed, 24 Aug 2022 17:57:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=ot0aEvyT380VjDU6PPl13tz+5G5649T71Q1QmyiGXIo=; b=YpSDVkBcxWVnnXfQXF/M7AZGWY5x+V+c24wMO5zVR8RFtXivElwnk0FLNTXke/emLT oh8/MGX4jyRJc+YrZXh96+Jtsdh8UfgCE6n4YSYTOMmu4AtkTQJ7laVjSVHJm8+QclNG oVzUJs4I5lvMg1LyJ9KO0CmiPyQ9FIcsSPJtg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=ot0aEvyT380VjDU6PPl13tz+5G5649T71Q1QmyiGXIo=; b=1VfwAjWxI8cgVPN1VUK0rgO69yLxVJRBW1xSNJgyIFQuzczPL4W11ZnNvacLpB/UnB 7aQZj3BZG1MUobNhH4yi6ErAi25hkRgtEbehRxhzr7sK9grpehFefGFdc0qMfN39G36L d6ruxVtLlWEQc8HsL3DwASs9hMDRDYxUnCwVTCcSaRwdgYSQ9VH9HdcZeHhuaqf/HUkl D4syja5DDjr8+n3MSxbNTK7hiPvPmbUoh9eDhHaEgNLLdCrqBIJoHwBNpyrpmM7AuCzY 7sWwLiF4IdLj2FlO4y1WusR4UcuIZLQK+tCH+YkXk4W0CROcRaES2yafivjx1f9ht8KH CT1w== X-Gm-Message-State: ACgBeo3aM8GSayOyzXefV9kdPu4/OAAa9X30UMy8KA96xCsSMG6vTpIV g9nAJWAC62alnuC37E7LPrQamO17Q8+TsY5oKL0= X-Google-Smtp-Source: AA6agR4r7Pys8QuX5y8fz0iFyO7/Len3YoE1TWd8qUOMqs8HUg5Gy1DcmkjCMrHSyutP2eHogy2CxA== X-Received: by 2002:a05:6402:3408:b0:43c:2dd3:d86b with SMTP id k8-20020a056402340800b0043c2dd3d86bmr1231965edc.108.1661389076810; Wed, 24 Aug 2022 17:57:56 -0700 (PDT) Received: from mail-ej1-f43.google.com (mail-ej1-f43.google.com. [209.85.218.43]) by smtp.gmail.com with ESMTPSA id g11-20020a170906538b00b0073dbaeb50f6sm1349710ejo.169.2022.08.24.17.57.56 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 24 Aug 2022 17:57:56 -0700 (PDT) Received: by mail-ej1-f43.google.com with SMTP id u15so27971995ejt.6 for ; Wed, 24 Aug 2022 17:57:56 -0700 (PDT) X-Received: by 2002:adf:e843:0:b0:225:221f:262 with SMTP id d3-20020adfe843000000b00225221f0262mr764111wrn.193.1661388757863; Wed, 24 Aug 2022 17:52:37 -0700 (PDT) MIME-Version: 1.0 References: <20210423230609.13519-1-alx.manpages@gmail.com> <20220824185505.56382-1-alx.manpages@gmail.com> In-Reply-To: From: Linus Torvalds Date: Wed, 24 Aug 2022 17:52:21 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3] Many pages: Document fixed-width types with ISO C naming To: Alejandro Colomar Cc: Alexei Starovoitov , Alex Colomar , Alexei Starovoitov , linux-man , Greg Kroah-Hartman , Daniel Borkmann , Zack Weinberg , LKML , glibc , GCC , bpf , LTP List , Linux API , linux-arch , David Laight , Joseph Myers , Florian Weimer , Cyril Hrubis , David Howells , Arnd Bergmann , Rich Felker , Adhemerval Zanella , Michael Kerrisk Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Wed, Aug 24, 2022 at 4:36 PM Alejandro Colomar wrote: > > I'm trying to be nice, and ask for review to make sure I'm not making > some big mistake by accident, and I get disrespect? No thanks. You've been told multiple times that the kernel doesn't use the "standard" names, and *cannot* use them for namespace reasons, and you ignore all the feedback, and then you claim you are asking for review? That's not "asking for review". That's "I think I know the answer, and when people tell me otherwise I ignore them". The fact is, kernel UAPI header files MUST NOT use the so-called standard names. We cannot provide said names, because they are only provided by the standard header files. And since kernel header files cannot provide them, then kernel UAPI header files cannot _use_ them. End result: any kernel UAPI header file will continue to use __u32 etc naming that doesn't have any namespace pollution issues. Nothing else is even remotely acceptable. Stop trying to make this something other than it is. And if you cannot accept these simple technical reasons, why do you expect respect? Why are you so special that you think you can change the rules for kernel uapi files over the *repeated* objections from maintainers who know better? Linus