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: <476BC71A.40806@msgid.tls.msk.ru>
Date:	Fri, 21 Dec 2007 17:00:58 +0300
From:	Michael Tokarev <mjt@....msk.ru>
To:	Johannes Weiner <hannes@...urebad.de>
CC:	"Rafael J. Wysocki" <rjw@...k.pl>,
	LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Dave Jones <davej@...emonkey.org.uk>
Subject: Re: 2.6.24-rc5-git7: Reported regressions from 2.6.23

Johannes Weiner wrote:
[]
> I still have a bug with cpufreq when using ondemand governor as default.
> 
> The performance governor, which has been the essential default until
> 1c2562459faedc35927546cfa5273ec6c2884cce,  was initialized with
> fs_initcall() instead of module_init() to make sure the driver is up and
> running when the bootcode (speedstep_init in my case) calls into it.
> 
> Since the above mentioned commit, other governors can also be chosen to
> be the default but they are not correctly initialized before first use
> then.

By the way, is there any real need to specify default governor at
a compile time in the first place?  Performance governor (which was
the only default so far) is a very simple one (not large to consider
its size effects for embedded systems for example), and switching
governors at run time is trivial as well.  What's the motivation
behind this new config option?

[]
> This migrates all governors from module_init() to fs_initcall() when
> being the default, as was already done in cpufreq_performance when it
> was the only possible choice.

Oh well.  Which leads to more surprises in the future, I think...

Thanks.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ