Hello, On Fri, 2013-08-23 at 12:24 -0400, Tejun Heo wrote: > On Fri, Aug 23, 2013 at 10:14:08AM -0600, Toshi Kani wrote: > > I still think acpi table info should be available earlier, but I do not > > think I can convince you on this. This can be religious debate. > > I'm curious. If there aren't substantial enough benefits, why would > you still want to pull it earlier when it brings in things like initrd > override and crafting the code carefully so that it's safe to execute > it from different address modes and so on? Please note that x86 is > not ia64. The early environment is completely different not only > technically but also in its diversity and suckiness. It wasn't too > long ago that vendors were screwing up ACPI left and right. It has > been getting better but there's a reason why, for example, we still > consider e820 to be the authoritative information over ACPI. Firmware generates tables, and provides them via some interface. Memory map table can be provided via e820 or EFI memory map. Memory topology table is provided via ACPI. I agree to prioritize one table over the other when there is overlap. But in the end, it is the firmware that generates the tables. Because it is provided via ACPI does not make it suddenly unreliable. I think table info from e820/EFI/ACPI should be available at the same time. To me, it makes more sense to use the hotplug info to initialize memblock than try to find a way to workaround without it. I think we will continue to be in that way to find a workaround in this direction. I came from ia64 background, and am not very familiar with x86. So, you may be very right about that x86 is different. I also agree that initrd is making it unnecessarily complicated. We may see some initial issues, but my hope is that the code gets matured over the time. Thanks, -Toshi -- 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
