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] [day] [month] [year] [list]
Message-ID: <20110113162222.GA10792@dirshya.in.ibm.com>
Date:	Thu, 13 Jan 2011 21:52:22 +0530
From:	Vaidyanathan Srinivasan <svaidy@...ux.vnet.ibm.com>
To:	Arjan van de Ven <arjan@...ux.intel.com>
Cc:	Trinabh Gupta <trinabh@...ux.vnet.ibm.com>, peterz@...radead.org,
	lenb@...nel.org, suresh.b.siddha@...el.com,
	benh@...nel.crashing.org, venki@...gle.com, ak@...ux.intel.com,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC V2 3/3] cpuidle: default idle driver for x86

* Arjan van de Ven <arjan@...ux.intel.com> [2011-01-13 07:47:16]:

> On 1/13/2011 4:52 AM, Trinabh Gupta wrote:
> >This default cpuidle_driver parses idle= boot parameters, selects
> >the optimal idle routine for x86 during bootup and registers with
> >cpuidle. The code for idle routines and the selection of optimal
> >routine is moved from arch/x86/kernel/process.c . At module_init this
> >default driver is registered with cpuidle and for non ACPI platforms
> >it continues to be used. For ACPI platforms, acpi_idle driver would
> >replace this driver at a later point in time during bootup. Until
> >this driver's registration, architecture supplied compile time
> >default idle routine is called from within cpuidle_idle_call().
> >
> 
> 
> I like the general approach, but I'd think making idle drivers
> modular is going one step too far....
> that looks like waaay overkill to me (also since most of the actual
> idle handlers are so small
> that the overhead of the exported symbols alone is bigger than the
> idle handlers)

Agreed.  The idea of keeping them in a module is to keep the code
around for legacy systems and not have to use that code at all on
modern systems where ACPI driver can take over.

The current RFC still has not managed to pull out all the code into
the module, but suggest that it is possible.

We can keep them in-kernel and move to the next iteration where we
should ensure other architectures also can co-exist with pm_idle() and
slowly move to this approach.

--Vaidy

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