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:

quoted

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.

quoted

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/>