Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755055AbZJEWmW (ORCPT ); Mon, 5 Oct 2009 18:42:22 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754537AbZJEWmU (ORCPT ); Mon, 5 Oct 2009 18:42:20 -0400 Received: from smtp1.linux-foundation.org ([140.211.169.13]:50078 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753963AbZJEWmT (ORCPT ); Mon, 5 Oct 2009 18:42:19 -0400 Date: Mon, 5 Oct 2009 15:40:21 -0700 From: Andrew Morton To: Len Brown Cc: rjw@sisk.pl, balbir@linux.vnet.ibm.com, torvalds@linux-foundation.org, linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, a.p.zijlstra@chello.nl, shaohua.li@intel.com, svaidy@linux.vnet.ibm.com Subject: Re: [git pull request] ACPI Processor Aggregator Driver for 2.6.32-rc1 Message-Id: <20091005154021.129a8f9f.akpm@linux-foundation.org> In-Reply-To: References: <20091005033256.GA26592@balbir.in.ibm.com> <200910052159.24920.rjw@sisk.pl> <20091005140415.57f1db5e.akpm@linux-foundation.org> X-Mailer: Sylpheed version 2.2.4 (GTK+ 2.8.20; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1619 Lines: 37 On Mon, 05 Oct 2009 18:20:44 -0400 (EDT) Len Brown wrote: > > Technical question: the overall feature, which I'd describe as > > "shutting down CPUs when an external agent tells us the > > thermal/electrical/other load is too high" is not at all specific to > > the x86 CPU. Should the code have been designed in such a way as to > > permit other architectures to play? > > I agree with Peter and Vaidy that a generic capability in the Linux > scheduler would be wonderful. But we don't have that today. > > Re: this driver in particular... > acpi_pad accepts an ACPI event from the platform and then > does something with it. > > Today, ACPI runs on just x86 and ia64, and I'm not aware > of any plans to implement this particularly feature on ia64 platforms. The sysfs handling looks generic and the driver can clearly be split into upper and lower layers, with all the ACPI specificity in the lower one. One would need to poll the arch maintainers to find out whether that's a desirable thing to attempt at the intial stage. If it _is_ desirable then there's now a risk that the interfaces and possibly behaviour will change in non-back-compatible ways. Or they will be stuck with ugly back-compatibility things But it's all too late now, isn't it. This is the first time that non-linux-acpi readers knew of the existence of this driver. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/