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

[Toshi Kani]

Hello Tejun,

On Wed, 2013-08-21 at 16:40 -0400, Tejun Heo wrote:
> On Wed, Aug 21, 2013 at 02:29:28PM -0600, Toshi Kani wrote:
> > Platforms vendors (which care Linux) need to support the existing Linux
> > features.  This means that they have to implement legacy interfaces on
> > x86 until the kernel supports an alternative method.  For instance, some
> > platforms are legacy-free and do not have legacy COM ports.  These ACPI
> > tables were defined so that non-legacy COM ports can be described and
> > informed to the OS.  Without this support, such platforms may have to
> > emulate the legacy COM ports for Linux, or drop Linux support.
> 
> Are you seriously saying that vendors are gonna drop linux support for
> lacking ACPI earlyprintk support?  Please...

earlyprintk is an example of the issues.  The point is that vendors are
required to support legacy stuff for Linux.

> Please take a look at the existing earlyprintk code and how compact
> and self-contained they are.  If you want to add ACPI earlyprintk, do
> similar stuff.  Forget about firmware blob override from initrd or
> ACPICA.  Just implement the bare minimum to get the thing working.  Do
> not add dependency to large body of code from earlyboot.  It's a bad
> idea through and through.

I am not saying that ACPI earlyprintk must be available at exactly the
same point.  How early it can reasonably be is a subject of discussion.

> > I think the kernel boot-up sequence should be designed in such a way
> > that can support legacy-free and/or NUMA platforms properly.
> 
> Blanket statements like the above don't mean much.  There are many
> separate stages of boot and you're talking about one of the very first
> stages where we traditionally have always depended upon only the very
> bare minimum of the platform both in hardware itself and configuration
> information.  We've been doing that for *very* good reasons.  If you
> screw up there, it's mighty tricky to figure out what went wrong
> especially on the machines that you can't physically kick.  You're now
> suggesting to add whole ACPI parsing including overloading from initrd
> into that stage with pretty weak rationale.

I agree that ACPI is rather complicated stuff.  But in my experience,
the majority complication comes from ACPI namespace and methods, not
from ACPI tables.  Do you really think ACPI table init is that risky?  I
consider ACPI tables are part of the minimum config info, esp. for
legacy-free platforms.

> Seriously, if you want ACPI based earlyprintk, implement it in a
> discrete minimal code which is easy to verify and won't get affected
> when the rest of ACPI machinery is updated.  We really don't want
> earlyboot to fail because someone screwed up ACPI or initrd handling.

earlyprintk is just another example to this SRAT issue.  The local page
table is yet another example.  My hope here is for us to be able to
utilize ACPI tables properly without hitting this kind of ordering
issues again and again, which requires considerable time & effort to
address.

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/