From: Bjorn Helgaas <bjorn.helgaas@hp.com>
To: Jes Sorensen <jes@trained-monkey.org>, linux-kernel@vger.kernel.org
Subject: Re: [ACPI] RFC: ACPI table overflow handling
Date: Thu, 8 Jan 2004 09:20:04 -0700
User-Agent: KMail/1.5.4
Cc: acpi-devel@lists.sourceforge.net, jbarnes@sgi.com, steiner@sgi.com
References: <16381.27904.580087.442358@gargle.gargle.HOWL>
In-Reply-To: <16381.27904.580087.442358@gargle.gargle.HOWL>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200401080920.04906.bjorn.helgaas@hp.com>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 908
Lines: 17

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.

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