linux-kernel - Re: [PATCH] cpufreq: fix UP build

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: <alpine.LFD.2.01.0907081103560.3352@localhost.localdomain>
Date:	Wed, 8 Jul 2009 11:08:12 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Alexander Beregalov <a.beregalov@...il.com>
cc:	linux-kernel@...r.kernel.org, mathieu.desnoyers@...ymtl.ca,
	davej@...hat.com
Subject: Re: [PATCH] cpufreq: fix UP build

On Wed, 8 Jul 2009, Alexander Beregalov wrote:
>
> From: Alexander Beregalov <a.beregalov@...il.com> 
> 
> Fix this build error when CONFIG_SMP is not set:
> drivers/cpufreq/cpufreq.c:941: 'managed_policy' undeclared

Grr. DaveJ?

That said, I'd much prefer the fix that does _not_ have this crap in it 
(not new to your diff - it's pre-existing crap):

	>  #ifdef CONFIG_SMP
	>       struct cpufreq_policy *managed_policy;
	> +     struct sys_device *cpu_sys_dev;
	>  #endif

and instead those variables should be declared inside the blocks where 
they are used, not at the top.

The rule should always be: make the scope of a variable as small as 
possible. Don't declare it at the top and try to "save" a declaration when 
it can be used inside multiple blocks as multiple different variables.

Also, that whole function could damn well be split into smaller pieces, 
which would make it much more readable than that horrible 250+ line piece 
of crap monster-function with #ifdef's inside the code.

Please, somebody?

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