linux-kernel - Re: [PATCH 0/8] x86, acpi: Move acpi_initrd

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1377278016.10300.814.camel@misato.fc.hp.com>
Date:	Fri, 23 Aug 2013 11:13:36 -0600
From:	Toshi Kani <toshi.kani@...com>
To:	Tejun Heo <tj@...nel.org>
Cc:	Zhang Yanfei <zhangyanfei.yes@...il.com>,
	Tang Chen <tangchen@...fujitsu.com>, konrad.wilk@...cle.com,
	robert.moore@...el.com, lv.zheng@...el.com, rjw@...k.pl,
	lenb@...nel.org, tglx@...utronix.de, mingo@...e.hu, hpa@...or.com,
	akpm@...ux-foundation.org, trenn@...e.de, yinghai@...nel.org,
	jiang.liu@...wei.com, wency@...fujitsu.com, laijs@...fujitsu.com,
	isimatu.yasuaki@...fujitsu.com, izumi.taku@...fujitsu.com,
	mgorman@...e.de, minchan@...nel.org, mina86@...a86.com,
	gong.chen@...ux.intel.com, vasilis.liaskovitis@...fitbricks.com,
	lwoodman@...hat.com, riel@...hat.com, jweiner@...hat.com,
	prarit@...hat.com, zhangyanfei@...fujitsu.com,
	yanghy@...fujitsu.com, x86@...nel.org, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	linux-acpi@...r.kernel.org
Subject: Re: [PATCH 0/8] x86, acpi: Move acpi_initrd_override() earlier.

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/