Re: [PATCH 0/8] x86, acpi: Move acpi_initrd_override() earlier.

[Toshi Kani]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/