Hello, Toshi. 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... 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 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. 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. Thanks. -- tejun -- 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
