Re: RFC: ACPI table overflow handling

[Jes Sorensen <jes-UC6nUKlm/0l5V+5IkYBVeNBPR1lH4CV8@public.gmane.org>]

>>>>> "Bjorn" == Bjorn Helgaas <bjorn.helgaas-VXdhtT5mjnY@public.gmane.org> writes:

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

Bjorn> I really like this idea.  I notice you didn't take the
Bjorn> opportunity to remove the ad hoc checking in ia64
Bjorn> acpi_parse_lsapic; probably that's the next step.  Also, did
Bjorn> you consider using max_entries==0 to signify "unlimited"?  Zero
Bjorn> seems like an otherwise useless value for max_entries and would
Bjorn> avoid having to choose an arbitrary limit.

Hi Bjorn,

Since it seems my efforts weren't for nothing then I'll take another
round on this one and clean it up further. Zero is such a pretty
number so I agree, lets make that be unlimited.

Cheers,
Jes


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