On 8/25/22 09:44, Alejandro Colomar wrote:
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 hevaguely 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 toprovide 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
... are intended mostly for kernel-space programmers?
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-hCheers, Alex
-- Alejandro Colomar <http://www.alejandro-colomar.es/>
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
