Hi Toshi, On 08/24/2013 01:13 AM, Toshi Kani wrote: > 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. Yeah, agreed. But sigh.... on x86, we have ACPI initrd override, so we still cannot convince Tj.... 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 > -- Thanks. Zhang Yanfei -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
