From: Tejun Heo <tj@kernel.org> To: Toshi Kani <toshi.kani@hp.com> Cc: Zhang Yanfei <zhangyanfei.yes@gmail.com>, Tang Chen <tangchen@cn.fujitsu.com>, konrad.wilk@oracle.com, robert.moore@intel.com, lv.zheng@intel.com, rjw@sisk.pl, lenb@kernel.org, tglx@linutronix.de, mingo@elte.hu, hpa@zytor.com, akpm@linux-foundation.org, trenn@suse.de, yinghai@kernel.org, jiang.liu@huawei.com, wency@cn.fujitsu.com, laijs@cn.fujitsu.com, isimatu.yasuaki@jp.fujitsu.com, izumi.taku@jp.fujitsu.com, mgorman@suse.de, minchan@kernel.org, mina86@mina86.com, gong.chen@linux.intel.com, vasilis.liaskovitis@profitbricks.com, lwoodman@redhat.com, riel@redhat.com, jweiner@redhat.com, prarit@redhat.com, zhangyanfei@cn.fujitsu.com, yanghy@cn.fujitsu.com, x86@kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-acpi@vger.kernel.org Subject: Re: [PATCH 0/8] x86, acpi: Move acpi_initrd_override() earlier. Date: Wed, 21 Aug 2013 16:40:41 -0400 [thread overview] Message-ID: <20130821204041.GC2436@htj.dyndns.org> (raw) In-Reply-To: <1377116968.10300.514.camel@misato.fc.hp.com> 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
WARNING: multiple messages have this Message-ID (diff)
From: Tejun Heo <tj@kernel.org> To: Toshi Kani <toshi.kani@hp.com> Cc: Zhang Yanfei <zhangyanfei.yes@gmail.com>, Tang Chen <tangchen@cn.fujitsu.com>, konrad.wilk@oracle.com, robert.moore@intel.com, lv.zheng@intel.com, rjw@sisk.pl, lenb@kernel.org, tglx@linutronix.de, mingo@elte.hu, hpa@zytor.com, akpm@linux-foundation.org, trenn@suse.de, yinghai@kernel.org, jiang.liu@huawei.com, wency@cn.fujitsu.com, laijs@cn.fujitsu.com, isimatu.yasuaki@jp.fujitsu.com, izumi.taku@jp.fujitsu.com, mgorman@suse.de, minchan@kernel.org, mina86@mina86.com, gong.chen@linux.intel.com, vasilis.liaskovitis@profitbricks.com, lwoodman@redhat.com, riel@redhat.com, jweiner@redhat.com, prarit@redhat.com, zhangyanfei@cn.fujitsu.com, yanghy@cn.fujitsu.com, x86@kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-acpi@vger.kernel.org Subject: Re: [PATCH 0/8] x86, acpi: Move acpi_initrd_override() earlier. Date: Wed, 21 Aug 2013 16:40:41 -0400 [thread overview] Message-ID: <20130821204041.GC2436@htj.dyndns.org> (raw) In-Reply-To: <1377116968.10300.514.camel@misato.fc.hp.com> 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, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2013-08-21 20:40 UTC|newest] Thread overview: 116+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-08-21 10:15 [PATCH 0/8] x86, acpi: Move acpi_initrd_override() earlier Tang Chen 2013-08-21 10:15 ` Tang Chen 2013-08-21 10:15 ` [PATCH 1/8] x86: Make get_ramdisk_{image|size}() global Tang Chen 2013-08-21 10:15 ` Tang Chen 2013-08-21 10:15 ` [PATCH 2/8] x86, microcode: Use get_ramdisk_{image|size}() in microcode handling Tang Chen 2013-08-21 10:15 ` Tang Chen 2013-08-21 10:15 ` [PATCH 3/8] x86, acpi: Move table_sigs[] to stack Tang Chen 2013-08-21 10:15 ` Tang Chen 2013-08-21 10:15 ` [PATCH 4/8] x86, acpi, brk: Extend BRK 256KB to store acpi override tables Tang Chen 2013-08-21 10:15 ` Tang Chen 2013-08-21 10:15 ` [PATCH 5/8] x86, brk: Make extend_brk() available with va/pa Tang Chen 2013-08-21 10:15 ` Tang Chen 2013-08-21 12:26 ` Konrad Rzeszutek Wilk 2013-08-21 12:26 ` Konrad Rzeszutek Wilk 2013-08-21 12:35 ` H. Peter Anvin 2013-08-21 12:35 ` H. Peter Anvin 2013-08-21 14:42 ` Konrad Rzeszutek Wilk 2013-08-21 14:42 ` Konrad Rzeszutek Wilk 2013-08-21 15:04 ` H. Peter Anvin 2013-08-21 15:04 ` H. Peter Anvin 2013-08-21 10:15 ` [PATCH 6/8] x86, acpi: Make acpi_initrd_override() available with va or pa Tang Chen 2013-08-21 10:15 ` Tang Chen 2013-08-21 10:15 ` [PATCH 7/8] x86, acpi, brk: Make early_alloc_acpi_override_tables_buf() available with va/pa Tang Chen 2013-08-21 10:15 ` Tang Chen 2013-08-21 10:15 ` [PATCH 8/8] x86, acpi: Do acpi_initrd_override() earlier in head_32.S/head64.c Tang Chen 2013-08-21 10:15 ` Tang Chen 2013-08-21 10:42 ` [PATCH 0/8] x86, acpi: Move acpi_initrd_override() earlier Tang Chen 2013-08-21 10:42 ` Tang Chen 2013-08-21 13:06 ` Tejun Heo 2013-08-21 13:06 ` Tejun Heo 2013-08-21 15:00 ` Zhang Yanfei 2013-08-21 15:00 ` Zhang Yanfei 2013-08-21 15:36 ` Tejun Heo 2013-08-21 15:36 ` Tejun Heo 2013-08-21 19:31 ` Toshi Kani 2013-08-21 19:31 ` Toshi Kani 2013-08-21 19:54 ` Tejun Heo 2013-08-21 19:54 ` Tejun Heo 2013-08-21 20:29 ` Toshi Kani 2013-08-21 20:29 ` Toshi Kani 2013-08-21 20:40 ` Tejun Heo [this message] 2013-08-21 20:40 ` Tejun Heo 2013-08-21 22:36 ` Toshi Kani 2013-08-21 22:36 ` Toshi Kani 2013-08-22 3:32 ` Tejun Heo 2013-08-22 3:32 ` Tejun Heo 2013-08-22 15:52 ` Toshi Kani 2013-08-22 15:52 ` Toshi Kani 2013-08-22 18:31 ` Tejun Heo 2013-08-22 18:31 ` Tejun Heo 2013-08-22 19:39 ` Zhang Yanfei 2013-08-22 19:39 ` Zhang Yanfei 2013-08-22 19:45 ` Tejun Heo 2013-08-22 19:45 ` Tejun Heo 2013-08-22 20:11 ` Toshi Kani 2013-08-22 20:11 ` Toshi Kani 2013-08-22 20:21 ` Tejun Heo 2013-08-22 20:21 ` Tejun Heo 2013-08-22 20:35 ` Tejun Heo 2013-08-22 20:35 ` Tejun Heo 2013-08-22 21:06 ` Toshi Kani 2013-08-22 21:06 ` Toshi Kani 2013-08-22 21:21 ` Tejun Heo 2013-08-22 21:21 ` Tejun Heo 2013-08-22 22:17 ` Toshi Kani 2013-08-22 22:17 ` Toshi Kani 2013-08-23 13:04 ` Tejun Heo 2013-08-23 13:04 ` Tejun Heo 2013-08-23 13:08 ` H. Peter Anvin 2013-08-23 13:08 ` H. Peter Anvin 2013-08-23 14:19 ` Tejun Heo 2013-08-23 14:19 ` Tejun Heo 2013-08-23 14:24 ` H. Peter Anvin 2013-08-23 14:24 ` H. Peter Anvin 2013-08-23 14:24 ` H. Peter Anvin 2013-08-23 14:35 ` Tejun Heo 2013-08-23 14:35 ` Tejun Heo 2013-08-23 14:57 ` Tejun Heo 2013-08-23 14:57 ` Tejun Heo 2013-08-23 16:14 ` Toshi Kani 2013-08-23 16:14 ` Toshi Kani 2013-08-23 16:24 ` Tejun Heo 2013-08-23 16:24 ` Tejun Heo 2013-08-23 17:13 ` Toshi Kani 2013-08-23 17:13 ` Toshi Kani 2013-08-23 17:29 ` Zhang Yanfei 2013-08-23 17:29 ` Zhang Yanfei 2013-08-23 16:54 ` Zhang Yanfei 2013-08-23 16:54 ` Zhang Yanfei 2013-08-23 18:18 ` Yinghai Lu 2013-08-23 18:18 ` Yinghai Lu 2013-08-23 18:25 ` H. Peter Anvin 2013-08-23 20:08 ` Yinghai Lu 2013-08-23 20:30 ` Russ Anderson 2013-08-23 20:48 ` Yinghai Lu 2013-08-23 21:50 ` chen tang 2013-08-23 21:52 ` Moore, Robert 2013-08-23 22:05 ` Yinghai Lu 2013-08-23 22:08 ` Yinghai Lu 2013-08-23 22:40 ` chen tang 2013-08-23 23:04 ` Yinghai Lu 2013-08-24 2:41 ` Russ Anderson 2013-08-23 20:33 ` chen tang 2013-08-23 20:33 ` chen tang 2013-08-23 21:08 ` Yinghai Lu 2013-08-23 21:08 ` Yinghai Lu 2013-08-23 22:27 ` chen tang 2013-08-23 22:27 ` chen tang 2013-08-23 18:29 ` Toshi Kani 2013-08-23 18:29 ` Toshi Kani 2013-08-23 21:37 ` chen tang 2013-08-23 21:37 ` chen tang 2013-08-23 21:52 ` Tejun Heo 2013-08-23 21:52 ` Tejun Heo 2013-08-23 23:56 ` chen tang 2013-08-23 23:56 ` chen tang
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20130821204041.GC2436@htj.dyndns.org \ --to=tj@kernel.org \ --cc=akpm@linux-foundation.org \ --cc=gong.chen@linux.intel.com \ --cc=hpa@zytor.com \ --cc=isimatu.yasuaki@jp.fujitsu.com \ --cc=izumi.taku@jp.fujitsu.com \ --cc=jiang.liu@huawei.com \ --cc=jweiner@redhat.com \ --cc=konrad.wilk@oracle.com \ --cc=laijs@cn.fujitsu.com \ --cc=lenb@kernel.org \ --cc=linux-acpi@vger.kernel.org \ --cc=linux-doc@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=lv.zheng@intel.com \ --cc=lwoodman@redhat.com \ --cc=mgorman@suse.de \ --cc=mina86@mina86.com \ --cc=minchan@kernel.org \ --cc=mingo@elte.hu \ --cc=prarit@redhat.com \ --cc=riel@redhat.com \ --cc=rjw@sisk.pl \ --cc=robert.moore@intel.com \ --cc=tangchen@cn.fujitsu.com \ --cc=tglx@linutronix.de \ --cc=toshi.kani@hp.com \ --cc=trenn@suse.de \ --cc=vasilis.liaskovitis@profitbricks.com \ --cc=wency@cn.fujitsu.com \ --cc=x86@kernel.org \ --cc=yanghy@cn.fujitsu.com \ --cc=yinghai@kernel.org \ --cc=zhangyanfei.yes@gmail.com \ --cc=zhangyanfei@cn.fujitsu.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.