linux-kernel - Re: [PATCH 1/2] 8139too: clean up spaces and TABs

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: <20080616093142.078f5528@extreme>
Date:	Mon, 16 Jun 2008 09:31:42 -0700
From:	Stephen Hemminger <shemminger@...tta.com>
To:	Stefan Richter <stefanr@...6.in-berlin.de>
Cc:	Németh Márton <nm127@...email.hu>,
	David Newall <davidn@...idnewall.com>,
	Jeff Garzik <jgarzik@...ox.com>, netdev@...r.kernel.org,
	Trivial Patch Monkey <trivial@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] 8139too: clean up spaces and TABs

On Mon, 16 Jun 2008 17:07:38 +0200
Stefan Richter <stefanr@...6.in-berlin.de> wrote:

> Németh Márton wrote:
> > I have chosen the checkpatch.pl's output to compare the
> > whether the old and the new code are better or not. Maybe that was a mistake.
> 
> Well, running checkpatch on source files (rather than patches) and
> fixing the files up according to checkpatch's output and own good
> judgement has two uses:
>   - bring new unmerged code into shape before submission,
>   - bring older mainline code into the canonical form as a basis
>     for further work.  You certainly saw how lots and lots of such
>     checkpatch-assisted cleanups went into arch/x86.  That's because
>     they were found useful for the work on unifying the two x86
>     architecture subtrees.
> So, a coding style rework has its use even on legacy code if people have
> plans with the code.  But keep in mind that (a) the whitespace rules
> aren't hard and universally agreed upon rules, (b) coding style has a
> number of other aspects of arguably greater importance than whitespace
> style, like proper modularization, good choices of names, use of common
> idioms and APIs instead of own inventions, and so on.

There is no point in doing this kind of checkpatch cleanup on its own.
It is worth doing more serious style work and rewriting of older drivers,
in the areas where other work needs to be done. Please work on drivers
that are ugly old vendor code, and/or you can find someone with the hardware
to test it.
--
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/