From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Hansen Subject: Re: [Lhms-devel] Re: [PATCH] ACPI based Memory Hotplug Driver Patch Date: Mon, 13 Sep 2004 01:41:05 -0700 Sender: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Message-ID: <1095064865.4671.5.camel@localhost> References: <20040910230200.73eb0374.tokunaga.keiich@jp.fujitsu.com> <1094837554.32531.1997.camel@nighthawk> <20040913172318.791db349.tokunaga.keiich@jp.fujitsu.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20040913172318.791db349.tokunaga.keiich-+CUm20s59erQFUHtdCDX3A@public.gmane.org> Errors-To: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: Keiichiro Tokunaga Cc: naveen.b.s-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org, Matthew E Tolentino , acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, lhms List-Id: linux-acpi@vger.kernel.org On Mon, 2004-09-13 at 01:23, Keiichiro Tokunaga wrote: > On Fri, 10 Sep 2004 10:32:35 -0700 Dave Hansen wrote: > > At this point, adding stuff to /proc in mainline has a pretty slim > > chance of happening. sysfs is really the way to go, plus we already > > have code in the mhp tree to export the hotplug memory controls via > > sysfs. This stuff seems to me to belong in /sys/firmware. > > > > But, this brings up something that's been nagging me for a while: what > > should /sys/devices/system/memory contain? A logical view of memory for > > use with memory hotplug, or a hardware description of memory? I think > > both are probably necessary, and should link to each other, but how > > should we present them? > > How about this? > > # ls /sys/firmware/acpi/memory/MEM1/ > resource_type > producer_consumer > decode > min_address > max_address > granularity > min_address_range > max_address_range > address_translation_offset > address_length The placement looks right to me. > # ls /sys/devices/system/memory/memsection4/ > start_physaddr > > > We can determine which memsection belongs to which ACPI > memory object by using min_address_range, max_address_range, > and start_physaddr. In the above case, start_physaddr is between > min_address_range and max_address_range if MEM1 contains > memsection4. sysfs really has a legacy of being linked together with regular old symlinks. There's plenty of stuff in there that we *could* derive by looking all over the place, but don't because it's so easy to just create links. I say we create links from one to the other, and make sure not to duplicate any information. For instance, there shouldn't really need to be a start_addr in the acpi directory if it can easily be determined from the memsections that belong to that acpi memory object. (or the othe way around, maybe) What we want to discourage is anybody writing ACPI-specific (or OpenFirmware on ppc for that matter) memory hotplug applications when a generic Linux one would do. That might be impossible in the long run, but it's worth a try. -- Dave ------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php