From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chen Gang Subject: Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it. Date: Tue, 28 May 2013 18:25:44 +0800 Message-ID: <51A48628.9030105@asianux.com> References: <519DCBEF.3090208@asianux.com> <20130523090534.GJ18614@n2100.arm.linux.org.uk> <201305231139.38233.arnd@arndb.de> <20130523100409.GK18614@n2100.arm.linux.org.uk> <20130528081910.GA29557@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20130528081910.GA29557@gmail.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linuxppc-dev-bounces+glppe-linuxppc-embedded-2=m.gmane.org@lists.ozlabs.org Sender: "Linuxppc-dev" To: Ingo Molnar Cc: Catalin Marinas , Linux-sh list , Heiko Carstens , "paulus@samba.org" , "H. Peter Anvin" , Michel Lespinasse , Hans-Christian Egtvedt , Linux-Arch , linux-s390@vger.kernel.org, Russell King - ARM Linux , uml-devel , Yoshinori Sato , Richard Weinberger , Helge Deller , the arch/x86 maintainers , "James E.J. Bottomley" , "mingo@redhat.com" , Geert Uytterhoeven , Frederic Weisbecker , Paul McKenney , H?vard Skinnemoen List-Id: linux-arch.vger.kernel.org On 05/28/2013 04:19 PM, Ingo Molnar wrote: >> > And I come back to one of my previous arguments - is it not better to >> > panic() if we hit one of these conditions so that the system can try to >> > do a panic-reboot rather than continue blindly into the unknown? > It will often continue blindly into the unknown even if the compiler is > happy ... > For Server, it is necessary to always enable CONFIG_BUG and call panic() When analyzing core dump or KDB trap, we have to assume that the kernel has already "continued blindly", but lucky, we can get the core dump or KDB trap finally (sometimes, we really even can not get core dump or KDB trap). For PC, it is useless to disable CONFIG_BUG The PC memory has already large enough to skip the minimal size optimization. And its speed is also high enough to skip the speed improvement by minimal size optimization. For Embedded system, some of architectures may disable CONFIG_BUG. Embedded system are widely used in many area, so the requirement of each architectures for BUG() may be different, some may need reboot as quickly as possible for urgent processing; some may need dead looping in BUG() for avoid user amazing; (if auto-reboot, users feel out of control, don't know what happens) some may still need panic() just like Server requirements. others may not care about it, just implement it as minimal size. > The only difference is that i t's "unpredictable" in a way not visible from > the C code: the code won't necessarily fall through the BUG() when hitting > that condition - although in practice it probably will. > > So I think the same principle applies to it as to any other debugging > code: it's fine to be able to turn debugging off. It's a performance > versus kernel robustness/determinism trade-off. 'minimal size' for BUG() is belongs to some of Embedded system specific features, it is not 'generic' enough to be in "include/asm-generic/". If we still provide the "disable CONFIG_BUG", some of 'crazy users' (e.g. randconfig) may make 'noise' to most of architectures. So we need not provide "disable CONFIG_BUG" features for all platforms, since most of architectures need not support it, and the architecture which really need minimal size, can implement it by itself as a architecture specific feature. Thanks. -- Chen Gang Asianux Corporation From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chen Gang Subject: Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it. Date: Tue, 28 May 2013 18:25:44 +0800 Message-ID: <51A48628.9030105@asianux.com> References: <519DCBEF.3090208@asianux.com> <20130523090534.GJ18614@n2100.arm.linux.org.uk> <201305231139.38233.arnd@arndb.de> <20130523100409.GK18614@n2100.arm.linux.org.uk> <20130528081910.GA29557@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: Catalin Marinas , Linux-sh list , Heiko Carstens , "paulus@samba.org" , "H. Peter Anvin" , Michel Lespinasse , Hans-Christian Egtvedt , Linux-Arch , linux-s390@vger.kernel.org, Russell King - ARM Linux , uml-devel , Yoshinori Sato , Richard Weinberger , Helge Deller , the arch/x86 maintainers , "James E.J. Bottomley" , "mingo@redhat.com" , Geert Uytterhoeven , Frederic Weisbecker , Paul McKenney , H?vard Skinnemoen , To: Ingo Molnar Return-path: In-Reply-To: <20130528081910.GA29557@gmail.com> List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linuxppc-dev-bounces+glppe-linuxppc-embedded-2=m.gmane.org@lists.ozlabs.org On 05/28/2013 04:19 PM, Ingo Molnar wrote: >> > And I come back to one of my previous arguments - is it not better to >> > panic() if we hit one of these conditions so that the system can try to >> > do a panic-reboot rather than continue blindly into the unknown? > It will often continue blindly into the unknown even if the compiler is > happy ... > For Server, it is necessary to always enable CONFIG_BUG and call panic() When analyzing core dump or KDB trap, we have to assume that the kernel has already "continued blindly", but lucky, we can get the core dump or KDB trap finally (sometimes, we really even can not get core dump or KDB trap). For PC, it is useless to disable CONFIG_BUG The PC memory has already large enough to skip the minimal size optimization. And its speed is also high enough to skip the speed improvement by minimal size optimization. For Embedded system, some of architectures may disable CONFIG_BUG. Embedded system are widely used in many area, so the requirement of each architectures for BUG() may be different, some may need reboot as quickly as possible for urgent processing; some may need dead looping in BUG() for avoid user amazing; (if auto-reboot, users feel out of control, don't know what happens) some may still need panic() just like Server requirements. others may not care about it, just implement it as minimal size. > The only difference is that i t's "unpredictable" in a way not visible from > the C code: the code won't necessarily fall through the BUG() when hitting > that condition - although in practice it probably will. > > So I think the same principle applies to it as to any other debugging > code: it's fine to be able to turn debugging off. It's a performance > versus kernel robustness/determinism trade-off. 'minimal size' for BUG() is belongs to some of Embedded system specific features, it is not 'generic' enough to be in "include/asm-generic/". If we still provide the "disable CONFIG_BUG", some of 'crazy users' (e.g. randconfig) may make 'noise' to most of architectures. So we need not provide "disable CONFIG_BUG" features for all platforms, since most of architectures need not support it, and the architecture which really need minimal size, can implement it by itself as a architecture specific feature. Thanks. -- Chen Gang Asianux Corporation From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <51A48628.9030105@asianux.com> Date: Tue, 28 May 2013 18:25:44 +0800 From: Chen Gang MIME-Version: 1.0 References: <519DCBEF.3090208@asianux.com> <20130523090534.GJ18614@n2100.arm.linux.org.uk> <201305231139.38233.arnd@arndb.de> <20130523100409.GK18614@n2100.arm.linux.org.uk> <20130528081910.GA29557@gmail.com> In-Reply-To: <20130528081910.GA29557@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it. To: Ingo Molnar Cc: Russell King - ARM Linux , Arnd Bergmann , Geert Uytterhoeven , H?vard Skinnemoen , Hans-Christian Egtvedt , Mike Frysinger , Yoshinori Sato , Richard Kuo , "James E.J. Bottomley" , Helge Deller , Benjamin Herrenschmidt , "paulus@samba.org" , Martin Schwidefsky , Heiko Carstens , linux390@de.ibm.com, Paul Mundt , Jeff Dike , Richard Weinberger , Thomas Gleixner , "mingo@redhat.com" , "H. Peter Anvin" , the arch/x86 maintainers , "Eric W. Biederman" , Serge Hallyn , Paul McKenney , Frederic Weisbecker , David Miller , Andrew Morton , Akinobu Mita , Catalin Marinas , Michel Lespinasse , Will Deacon , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "uclinux-dist-devel@blackfin.uclinux.org" , linux-hexagon@vger.kernel.org, Parisc List , "linuxppc-dev@lists.ozlabs.org" , linux-s390@vger.kernel.org, Linux-sh list , uml-devel , uml-user , Linux-Arch , Linus Torvalds List-ID: On 05/28/2013 04:19 PM, Ingo Molnar wrote: >> > And I come back to one of my previous arguments - is it not better to >> > panic() if we hit one of these conditions so that the system can try to >> > do a panic-reboot rather than continue blindly into the unknown? > It will often continue blindly into the unknown even if the compiler is > happy ... > For Server, it is necessary to always enable CONFIG_BUG and call panic() When analyzing core dump or KDB trap, we have to assume that the kernel has already "continued blindly", but lucky, we can get the core dump or KDB trap finally (sometimes, we really even can not get core dump or KDB trap). For PC, it is useless to disable CONFIG_BUG The PC memory has already large enough to skip the minimal size optimization. And its speed is also high enough to skip the speed improvement by minimal size optimization. For Embedded system, some of architectures may disable CONFIG_BUG. Embedded system are widely used in many area, so the requirement of each architectures for BUG() may be different, some may need reboot as quickly as possible for urgent processing; some may need dead looping in BUG() for avoid user amazing; (if auto-reboot, users feel out of control, don't know what happens) some may still need panic() just like Server requirements. others may not care about it, just implement it as minimal size. > The only difference is that i t's "unpredictable" in a way not visible from > the C code: the code won't necessarily fall through the BUG() when hitting > that condition - although in practice it probably will. > > So I think the same principle applies to it as to any other debugging > code: it's fine to be able to turn debugging off. It's a performance > versus kernel robustness/determinism trade-off. 'minimal size' for BUG() is belongs to some of Embedded system specific features, it is not 'generic' enough to be in "include/asm-generic/". If we still provide the "disable CONFIG_BUG", some of 'crazy users' (e.g. randconfig) may make 'noise' to most of architectures. So we need not provide "disable CONFIG_BUG" features for all platforms, since most of architectures need not support it, and the architecture which really need minimal size, can implement it by itself as a architecture specific feature. Thanks. -- Chen Gang Asianux Corporation From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from intranet.asianux.com (intranet.asianux.com [58.214.24.6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id F1C7F2C030E for ; Tue, 28 May 2013 20:26:43 +1000 (EST) Message-ID: <51A48628.9030105@asianux.com> Date: Tue, 28 May 2013 18:25:44 +0800 From: Chen Gang MIME-Version: 1.0 To: Ingo Molnar Subject: Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it. References: <519DCBEF.3090208@asianux.com> <20130523090534.GJ18614@n2100.arm.linux.org.uk> <201305231139.38233.arnd@arndb.de> <20130523100409.GK18614@n2100.arm.linux.org.uk> <20130528081910.GA29557@gmail.com> In-Reply-To: <20130528081910.GA29557@gmail.com> Content-Type: text/plain; charset=UTF-8 Cc: Catalin Marinas , Linux-sh list , Heiko Carstens , "paulus@samba.org" , "H. Peter Anvin" , Michel Lespinasse , Hans-Christian Egtvedt , Linux-Arch , linux-s390@vger.kernel.org, Russell King - ARM Linux , uml-devel , Yoshinori Sato , Richard Weinberger , Helge Deller , the arch/x86 maintainers , "James E.J. Bottomley" , "mingo@redhat.com" , Geert Uytterhoeven , Frederic Weisbecker , Paul McKenney , H?vard Skinnemoen , Serge Hallyn , Mike Frysinger , Arnd Bergmann , Will Deacon , Jeff Dike , Akinobu Mita , uml-user , "uclinux-dist-devel@blackfin.uclinux.org" , Thomas Gleixner , "linux-arm-kernel@lists.infradead.org" , Parisc List , Linus Torvalds , "linux-kernel@vger.kernel.org" , Richard Kuo , Paul Mundt , "Eric W. Biederman" , linux-hexagon@vger.kernel.org, Martin Schwidefsky , linux390@de.ibm.com, Andrew Morton , "linuxppc-dev@lists.ozlabs.org" , David Miller List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On 05/28/2013 04:19 PM, Ingo Molnar wrote: >> > And I come back to one of my previous arguments - is it not better to >> > panic() if we hit one of these conditions so that the system can try to >> > do a panic-reboot rather than continue blindly into the unknown? > It will often continue blindly into the unknown even if the compiler is > happy ... > For Server, it is necessary to always enable CONFIG_BUG and call panic() When analyzing core dump or KDB trap, we have to assume that the kernel has already "continued blindly", but lucky, we can get the core dump or KDB trap finally (sometimes, we really even can not get core dump or KDB trap). For PC, it is useless to disable CONFIG_BUG The PC memory has already large enough to skip the minimal size optimization. And its speed is also high enough to skip the speed improvement by minimal size optimization. For Embedded system, some of architectures may disable CONFIG_BUG. Embedded system are widely used in many area, so the requirement of each architectures for BUG() may be different, some may need reboot as quickly as possible for urgent processing; some may need dead looping in BUG() for avoid user amazing; (if auto-reboot, users feel out of control, don't know what happens) some may still need panic() just like Server requirements. others may not care about it, just implement it as minimal size. > The only difference is that i t's "unpredictable" in a way not visible from > the C code: the code won't necessarily fall through the BUG() when hitting > that condition - although in practice it probably will. > > So I think the same principle applies to it as to any other debugging > code: it's fine to be able to turn debugging off. It's a performance > versus kernel robustness/determinism trade-off. 'minimal size' for BUG() is belongs to some of Embedded system specific features, it is not 'generic' enough to be in "include/asm-generic/". If we still provide the "disable CONFIG_BUG", some of 'crazy users' (e.g. randconfig) may make 'noise' to most of architectures. So we need not provide "disable CONFIG_BUG" features for all platforms, since most of architectures need not support it, and the architecture which really need minimal size, can implement it by itself as a architecture specific feature. Thanks. -- Chen Gang Asianux Corporation From mboxrd@z Thu Jan 1 00:00:00 1970 From: gang.chen@asianux.com (Chen Gang) Date: Tue, 28 May 2013 18:25:44 +0800 Subject: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it. In-Reply-To: <20130528081910.GA29557@gmail.com> References: <519DCBEF.3090208@asianux.com> <20130523090534.GJ18614@n2100.arm.linux.org.uk> <201305231139.38233.arnd@arndb.de> <20130523100409.GK18614@n2100.arm.linux.org.uk> <20130528081910.GA29557@gmail.com> Message-ID: <51A48628.9030105@asianux.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 05/28/2013 04:19 PM, Ingo Molnar wrote: >> > And I come back to one of my previous arguments - is it not better to >> > panic() if we hit one of these conditions so that the system can try to >> > do a panic-reboot rather than continue blindly into the unknown? > It will often continue blindly into the unknown even if the compiler is > happy ... > For Server, it is necessary to always enable CONFIG_BUG and call panic() When analyzing core dump or KDB trap, we have to assume that the kernel has already "continued blindly", but lucky, we can get the core dump or KDB trap finally (sometimes, we really even can not get core dump or KDB trap). For PC, it is useless to disable CONFIG_BUG The PC memory has already large enough to skip the minimal size optimization. And its speed is also high enough to skip the speed improvement by minimal size optimization. For Embedded system, some of architectures may disable CONFIG_BUG. Embedded system are widely used in many area, so the requirement of each architectures for BUG() may be different, some may need reboot as quickly as possible for urgent processing; some may need dead looping in BUG() for avoid user amazing; (if auto-reboot, users feel out of control, don't know what happens) some may still need panic() just like Server requirements. others may not care about it, just implement it as minimal size. > The only difference is that i t's "unpredictable" in a way not visible from > the C code: the code won't necessarily fall through the BUG() when hitting > that condition - although in practice it probably will. > > So I think the same principle applies to it as to any other debugging > code: it's fine to be able to turn debugging off. It's a performance > versus kernel robustness/determinism trade-off. 'minimal size' for BUG() is belongs to some of Embedded system specific features, it is not 'generic' enough to be in "include/asm-generic/". If we still provide the "disable CONFIG_BUG", some of 'crazy users' (e.g. randconfig) may make 'noise' to most of architectures. So we need not provide "disable CONFIG_BUG" features for all platforms, since most of architectures need not support it, and the architecture which really need minimal size, can implement it by itself as a architecture specific feature. Thanks. -- Chen Gang Asianux Corporation