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 _at_ vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Follow-Ups:
- Re: [ACPI] RFC: ACPI table overflow handlingJes Sorensen
- Re: [ACPI] RFC: ACPI table overflow handlingJes Sorensen
- RFC: ACPI table overflow handlingJes Sorensen
- Prev by Date: Re: [autofs] [RFC] Towards a Modern Autofs
- Next by Date: Re: Relocation overflow with modules on Alpha
- Previous by thread: RFC: ACPI table overflow handling
- Next by thread: Re: [ACPI] RFC: ACPI table overflow handling
- Indexes:[Main][Thread]