linux-kernel - Re: [PATCH v3] Many pages: Document fixed-width types with ISO C naming

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <609e1161-87ee-bb48-d14c-dc444ddff754@gmail.com>
Date:   Thu, 25 Aug 2022 09:44:40 +0200
From:   Alejandro Colomar <alx.manpages@...il.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Alex Colomar <alx@...nel.org>,
        Alexei Starovoitov <ast@...nel.org>,
        linux-man <linux-man@...r.kernel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Zack Weinberg <zackw@...ix.com>,
        LKML <linux-kernel@...r.kernel.org>,
        glibc <libc-alpha@...rceware.org>, GCC <gcc-patches@....gnu.org>,
        bpf <bpf@...r.kernel.org>, LTP List <ltp@...ts.linux.it>,
        Linux API <linux-api@...r.kernel.org>,
        linux-arch <linux-arch@...r.kernel.org>,
        David Laight <David.Laight@...lab.com>,
        Joseph Myers <joseph@...esourcery.com>,
        Florian Weimer <fweimer@...hat.com>,
        Cyril Hrubis <chrubis@...e.cz>,
        David Howells <dhowells@...hat.com>,
        Arnd Bergmann <arnd@...db.de>, Rich Felker <dalias@...c.org>,
        Adhemerval Zanella <adhemerval.zanella@...aro.org>,
        Michael Kerrisk <mtk.manpages@...il.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH v3] Many pages: Document fixed-width types with ISO C
 naming

Hi Greg,

On 8/25/22 07:57, Greg Kroah-Hartman wrote:
> On Thu, Aug 25, 2022 at 01:36:10AM +0200, Alejandro Colomar wrote:
>> But from your side what do we have?  Just direct NAKs without much
>> explanation.  The only one who gave some explanation was Greg, and he
>> vaguely pointed to Linus's comments about it in the past, with no precise
>> pointer to it.  I investigated a lot before v2, and could not find anything
>> strong enough to recommend using kernel types in user space, so I pushed v2,
>> and the discussion was kept.
> 
> So despite me saying that "this is not ok", and many other maintainers
> saying "this is not ok", you applied a patch with our objections on it?
> That is very odd and a bit rude.
> 
>> I would like that if you still oppose to the patch, at least were able to
>> provide some facts to this discussion.
> 
> The fact is that the kernel can not use the namespace that userspace has
> with ISO C names.  It's that simple as the ISO standard does NOT
> describe the variable types for an ABI that can cross the user/kernel
> boundry.

I understand that.  But user-space programs are allowed to use the 
standard types when calling a syscall that really uses kernel types.

IMHO, it should be irrelevant for the user how the kernel decides to 
call a 64-bit unsigned integer, right?

Or do you mean that some of the pages I modified

> 
> Work with the ISO C standard if you wish to document such type usage,
> and get it approved and then we would be willing to consider such a
> change.  But until then, we have to stick to our variable name types,
> just like all other operating systems have to (we are not alone here.)
> 
> Please revert your change.

Thanks for asking nicely.

Since there's ongoing discussion, and I don't want to make it look like 
ignoring it, I've reverted the patch for now.  If I apply it again, I 
hope that it will be with some more consensus, as I've always tried to 
do.  Sorry if I was a bit irascible yesterday.  Shit happens.

TL;DR:  Patch reverted; asking nicely works. =)

> 
> greg k-h

Cheers,

Alex

-- 
Alejandro Colomar
<http://www.alejandro-colomar.es/>

Download attachment "OpenPGP_signature" of type "application/pgp-signature" (834 bytes)