From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bjorn Helgaas Subject: Re: RFC: ACPI table overflow handling Date: Thu, 8 Jan 2004 09:20:04 -0700 Sender: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Message-ID: <200401080920.04906.bjorn.helgaas@hp.com> References: <16381.27904.580087.442358@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <16381.27904.580087.442358-4mDQ13Tdud8Jw5R7aSpS0dP8p4LwMBBS@public.gmane.org> Content-Disposition: inline Errors-To: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: Jes Sorensen , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, jbarnes-sJ/iWh9BUns@public.gmane.org, steiner-sJ/iWh9BUns@public.gmane.org List-Id: linux-acpi@vger.kernel.org On Thursday 08 January 2004 7:45 am, Jes Sorensen wrote: > I could just hack the NUMA srat_num_cpus handling code to have a limit > as IMHO it is a lot cleaner to improve the acpi_table_parse_madt() API > by adding a max_entries argument and then have acpi_table_parse_madt > spit out a warning if it found too many entries. I really like this idea. I notice you didn't take the opportunity to remove the ad hoc checking in ia64 acpi_parse_lsapic; probably that's the next step. Also, did you consider using max_entries==0 to signify "unlimited"? Zero seems like an otherwise useless value for max_entries and would avoid having to choose an arbitrary limit. ------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html