On Sunday 12 August 2007 04:42, Len Brown wrote: > I hate to burst this bubble, > but we have evidence that the only reliable way to enumerate > processors on an ACPI systems is to parse the DSDT. Yes I agree MADT parsing is in this case significantly simpler and likely safer and the MADT has to be already correct anyways. The later fixing up of tables in CPU detect was always not very reliable and constant maintenance issue. > > No, this has nothing to do with the actual ACPI specification, > but "common industry practice". ie. what the BIOS vendors are > shipping that works with Windows but confuses Linux. > > This means that all the "parse the MADT early" stuff > is basically a waste of effort in the long term > where we will have to change when Linux enumerates > (and thus enables) the processors in the boot sequence. I think it's because LinuxBIOS which Y.H. is working on is unable/unwilling to supply any ACPI tables. So he prefers to kludge around it in the kernel to adapt to the ever changing hardware. I already had this argument recently about k8topology.c. It's getting messier and messier and I would really like to retire it (it was originally only written for a very early BIOS without SRAT); the only reason not to is LinuxBIOS. Apparently one problem is that the Linux ACPI code is not very friendly to partial tables (e.g. only SRAT); perhaps that is something that could be improved. I skipped these hacks for now because I'm quite sceptical of them. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
