linux-kernel - Re: [PATCH x86] [5/16] Replace hard coded reservations in x86-64 early boot code with dynamic table II

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]

Date:	Fri, 4 Jan 2008 19:06:50 +0100
From:	Andi Kleen <ak@...e.de>
To:	Sam Ravnborg <sam@...nborg.org>
Cc:	Andi Kleen <ak@...e.de>, Ingo Molnar <mingo@...e.hu>,
	peterz@...radead.org, linux-kernel@...r.kernel.org,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH x86] [5/16] Replace hard coded reservations in x86-64
	early boot code with dynamic table II

> What is then considered "obvious style issues" are today implemented
> as errors / warnings in checkpatch for the most part. Not everyone

In my experience checkpatch has a lot of false positives. e.g. when 
I run it over my pile 20+% of the warnings are just bogus. And in
a lot of other cases it is that the rules of thumbs it applies
do not apply to that specific case. 

e.g. example: when you have self test debugging code it is perfectly
fine to not use KERN_*

> agrees with what checkpatch says are errors/warnings but this is at
> least an more or less unambigious way to express these obvious cases.

It's not -- checkpatch is often wrong. 

> And this is far better than the maintainers choice of the day style.

You mean the one from Ingo with the random new lines? @) Perhaps.
I just ask that people use some common sense.

> > Same for tabs versus spaces. That is something no human should
> > need to care about. And it is something a machine can handle fine too 
> > anyways.
> Things turn red in my vi if no-one cares 

That's a problem of your vi. I'm sure it can be turned off.

Fortunately it's easily fixed.

>- and I have no magic tool
> to fix it here.

I wrote one now.

ftp://ftp.firstfloor.org/pub/ak/perl/converttabs

As you can see it was trivial.

> No-one should submit patches with white-space errors - thank you.

No I disagree. If white space is suddenly that important -- it is still
unclear to me why that should be -- then the right way to handle that is 
at the maintainer level while merging patches. But rejecting patches
for reasons that a trivial script can fix up is just unnecessary friction
in the merging process and unnecessary bureaucracy.

Unnecessary bureaucracy defined as in rituals that do not 
actually improve any code or prevent bugs (or even style). I must say I find 
it a little sad that Linux is dissolving into that now. Ok perhaps
it is the eventual fate of anything that has been around for quite a long time,
but it seems to get worse much quicker recently.

Anyways I have the script above included now here in my patch setup
scripts so future patches of mine will have tabs.

But the problem with your "rule" is that every of the hundreds
of Linux kernel contributors will need to do the same. And that's just 
ineffecient, waste of valuable human work and just doesn't make much sense.

It certainly won't improve Linux in any way.

-Andi

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/