All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chen Gang <gang.chen@asianux.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: "Catalin Marinas" <Catalin.Marinas@arm.com>,
	"Linux-sh list" <linux-sh@vger.kernel.org>,
	"Heiko Carstens" <heiko.carstens@de.ibm.com>,
	"paulus@samba.org" <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	"Michel Lespinasse" <walken@google.com>,
	"Hans-Christian Egtvedt" <egtvedt@samfundet.no>,
	Linux-Arch <linux-arch@vger.kernel.org>,
	linux-s390@vger.kernel.org,
	"Russell King - ARM Linux" <linux@arm.linux.org.uk>,
	uml-devel <user-mode-linux-devel@lists.sourceforge.net>,
	"Yoshinori Sato" <ysato@users.sourceforge.jp>,
	"Richard Weinberger" <richard@nod.at>,
	"Helge Deller" <deller@gmx.de>,
	"the arch/x86 maintainers" <x86@kernel.org>,
	"James E.J. Bottomley" <jejb@parisc-linux.org>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"Frederic Weisbecker" <fweisbec@gmail.com>,
	"Paul McKenney" <paulmck@linux.vnet.ibm.com>,
	"Håvard Skinnemoen" <hskinnemoen@gmail.com>
Subject: Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.
Date: Fri, 24 May 2013 12:17:26 +0800	[thread overview]
Message-ID: <519EE9D6.9010707@asianux.com> (raw)
In-Reply-To: <519ECCCF.8090909@asianux.com>

On 05/24/2013 10:13 AM, Chen Gang wrote:
> On 05/23/2013 10:10 PM, Geert Uytterhoeven wrote:
>> On Thu, May 23, 2013 at 2:50 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>>>> On Thu, May 23, 2013 at 02:09:02PM +0200, Arnd Bergmann wrote:
>>>>>> On Thursday 23 May 2013, Russell King - ARM Linux wrote:
>>>>>>>> This is the problem you guys are missing - unreachable() means "we lose
>>>>>>>> control of the CPU at this point".
>>>>>>
>>>>>> I'm absolutely aware of this. Again, the current behaviour of doing nothing
>>>>>> at all isn't very different from undefined behavior when you get when you
>>>>>> get to the end of a function returning a pointer without a "return" statement,
>>>>>> or when you return from a function that has determined that it is not safe
>>>>>> to continue.
>>>>
>>>> Running off the end of a function like that is a different kettle of fish.
>>>> The execution path is still as the compiler intends - what isn't is that
>>>> the data returned is likely to be random trash.
>>>>
>>>> That's _quite_ different from the CPU starting to execute the contents
>>>> of a literal data pool.
>> I agree it's best to e.g. trap and reboot.
> 

In fact: if enable CONFIG_BUG, but not enable HAVE_ARCH_BUG, the
default implementation is:

 47 #ifndef HAVE_ARCH_BUG
 48 #define BUG() do { \
 49         printk("BUG: failure at %s:%d/%s()!\n", __FILE__, __LINE__, __func__); \
 50         panic("BUG!"); \
 51 } while (0)
 52 #endif

So if we delete CONFIG_BUG, the default implementation will be almost
like panic(),  and in panic() itself, also calls printk() !!

So...

:-)



> After read the arch/*/include/asm/bug.h,
> 
> It seems panic() is not suitable for NOMMU platforms (only m68k use it,
> also need CONFIG_BUG and CONFIG_SUN3 enabled).
> 
> And unreachable() is need followed with an asm inline instruction (arm,
> x86, powerpc mips...).
> 
> And __builtin_trap() is "the mechanism used may vary from release to
> release so should not rely on any particular implementation" (ref to
> "http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html", used by m68k,
> sparc, ia64).
> 
> I can not find any *trap*() and *unreachable*() in "include/asm-generic/"
> 
> I can not find any suitable implementation which 'generic' enough to add
> in "include/asm-generic/" (and in fact, CONFIG_BUG itself is not
> 'generic' enough to be in "include/asm-generic/").
> 
> 
> At last, I still suggest to delete CONFIG_BUG, so most of architectures
> can skip this issue firstly.
> 
> Then for specific architectures, also can get 3 benefits:
> 
> a. the related maintainers can implement it as their own willing (not
> need discus it with another platform maintainers again);
> 
> b. the related maintainers can free use the platform specific features
> (which can not be used in "include/asm-generic/");
> 
> c. the related maintainers are more familiar their own architectures
> demands and requirements.
> 
> 
> 
> ----------- arch/m68k/include/asm/bug.h --------------------------------
> 
>   1 #ifndef _M68K_BUG_H
>   2 #define _M68K_BUG_H
>   3
>   4 #ifdef CONFIG_MMU
>   5 #ifdef CONFIG_BUG
>   6 #ifdef CONFIG_DEBUG_BUGVERBOSE
>   7 #ifndef CONFIG_SUN3
>   8 #define BUG() do { \
>   9         printk("kernel BUG at %s:%d!\n", __FILE__, __LINE__); \
>  10         __builtin_trap(); \
>  11 } while (0)
>  12 #else
>  13 #define BUG() do { \
>  14         printk("kernel BUG at %s:%d!\n", __FILE__, __LINE__); \
>  15         panic("BUG!"); \
>  16 } while (0)
>  17 #endif
>  18 #else
>  19 #define BUG() do { \
>  20         __builtin_trap(); \
>  21 } while (0)
>  22 #endif
>  23
>  24 #define HAVE_ARCH_BUG
>  25 #endif
>  26 #endif /* CONFIG_MMU */
>  27
>  28 #include <asm-generic/bug.h>
>  29
>  30 #endif
> 
> 
> 
> 
> Thanks.
> 


-- 
Chen Gang

Asianux Corporation

WARNING: multiple messages have this Message-ID (diff)
From: Chen Gang <gang.chen@asianux.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: "Russell King - ARM Linux" <linux@arm.linux.org.uk>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Håvard Skinnemoen" <hskinnemoen@gmail.com>,
	"Hans-Christian Egtvedt" <egtvedt@samfundet.no>,
	"Mike Frysinger" <vapier@gentoo.org>,
	"Yoshinori Sato" <ysato@users.sourceforge.jp>,
	"Richard Kuo" <rkuo@codeaurora.org>,
	"James E.J. Bottomley" <jejb@parisc-linux.org>,
	"Helge Deller" <deller@gmx.de>,
	"Benjamin Herrenschmidt" <benh@kernel.crashing.org>,
	"paulus@samba.org" <paulus@samba.org>,
	"Martin Schwidefsky" <schwidefsky@de.ibm.com>,
	"Heiko Carstens" <heiko.carstens@de.ibm.com>,
	linux390@de.ibm.com, "Paul Mundt" <lethal@linux-sh.org>,
	"Jeff Dike" <jdike@addtoit.com>,
	"Richard Weinberger" <richard@nod.at>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	"the arch/x86 maintainers" <x86@kernel.org>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	"Serge Hallyn" <serge.hallyn@canonical.com>,
	"Paul McKenney" <paulmck@linux.vnet.ibm.com>,
	"Frederic Weisbecker" <fweisbec@gmail.com>,
	"David Miller" <davem@davemloft.net>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Akinobu Mita" <akinobu.mita@gmail.com>,
	"Catalin Marinas" <Catalin.Marinas@arm.com>,
	"Michel Lespinasse" <walken@google.com>,
	"Will Deacon" <will.deacon@arm.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"uclinux-dist-devel@blackfin.uclinux.org"
	<uclinux-dist-devel@blackfin.uclinux.org>,
	linux-hexagon@vger.kernel.org,
	"Parisc List" <linux-parisc@vger.kernel.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	linux-s390@vger.kernel.org,
	"Linux-sh list" <linux-sh@vger.kernel.org>,
	uml-devel <user-mode-linux-devel@lists.sourceforge.net>,
	uml-user <user-mode-linux-user@lists.sourceforge.net>,
	Linux-Arch <linux-arch@vger.kernel.org>
Subject: Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.
Date: Fri, 24 May 2013 12:17:26 +0800	[thread overview]
Message-ID: <519EE9D6.9010707@asianux.com> (raw)
In-Reply-To: <519ECCCF.8090909@asianux.com>

On 05/24/2013 10:13 AM, Chen Gang wrote:
> On 05/23/2013 10:10 PM, Geert Uytterhoeven wrote:
>> On Thu, May 23, 2013 at 2:50 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>>>> On Thu, May 23, 2013 at 02:09:02PM +0200, Arnd Bergmann wrote:
>>>>>> On Thursday 23 May 2013, Russell King - ARM Linux wrote:
>>>>>>>> This is the problem you guys are missing - unreachable() means "we lose
>>>>>>>> control of the CPU at this point".
>>>>>>
>>>>>> I'm absolutely aware of this. Again, the current behaviour of doing nothing
>>>>>> at all isn't very different from undefined behavior when you get when you
>>>>>> get to the end of a function returning a pointer without a "return" statement,
>>>>>> or when you return from a function that has determined that it is not safe
>>>>>> to continue.
>>>>
>>>> Running off the end of a function like that is a different kettle of fish.
>>>> The execution path is still as the compiler intends - what isn't is that
>>>> the data returned is likely to be random trash.
>>>>
>>>> That's _quite_ different from the CPU starting to execute the contents
>>>> of a literal data pool.
>> I agree it's best to e.g. trap and reboot.
> 

In fact: if enable CONFIG_BUG, but not enable HAVE_ARCH_BUG, the
default implementation is:

 47 #ifndef HAVE_ARCH_BUG
 48 #define BUG() do { \
 49         printk("BUG: failure at %s:%d/%s()!\n", __FILE__, __LINE__, __func__); \
 50         panic("BUG!"); \
 51 } while (0)
 52 #endif

So if we delete CONFIG_BUG, the default implementation will be almost
like panic(),  and in panic() itself, also calls printk() !!

So...

:-)



> After read the arch/*/include/asm/bug.h,
> 
> It seems panic() is not suitable for NOMMU platforms (only m68k use it,
> also need CONFIG_BUG and CONFIG_SUN3 enabled).
> 
> And unreachable() is need followed with an asm inline instruction (arm,
> x86, powerpc mips...).
> 
> And __builtin_trap() is "the mechanism used may vary from release to
> release so should not rely on any particular implementation" (ref to
> "http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html", used by m68k,
> sparc, ia64).
> 
> I can not find any *trap*() and *unreachable*() in "include/asm-generic/"
> 
> I can not find any suitable implementation which 'generic' enough to add
> in "include/asm-generic/" (and in fact, CONFIG_BUG itself is not
> 'generic' enough to be in "include/asm-generic/").
> 
> 
> At last, I still suggest to delete CONFIG_BUG, so most of architectures
> can skip this issue firstly.
> 
> Then for specific architectures, also can get 3 benefits:
> 
> a. the related maintainers can implement it as their own willing (not
> need discus it with another platform maintainers again);
> 
> b. the related maintainers can free use the platform specific features
> (which can not be used in "include/asm-generic/");
> 
> c. the related maintainers are more familiar their own architectures
> demands and requirements.
> 
> 
> 
> ----------- arch/m68k/include/asm/bug.h --------------------------------
> 
>   1 #ifndef _M68K_BUG_H
>   2 #define _M68K_BUG_H
>   3
>   4 #ifdef CONFIG_MMU
>   5 #ifdef CONFIG_BUG
>   6 #ifdef CONFIG_DEBUG_BUGVERBOSE
>   7 #ifndef CONFIG_SUN3
>   8 #define BUG() do { \
>   9         printk("kernel BUG at %s:%d!\n", __FILE__, __LINE__); \
>  10         __builtin_trap(); \
>  11 } while (0)
>  12 #else
>  13 #define BUG() do { \
>  14         printk("kernel BUG at %s:%d!\n", __FILE__, __LINE__); \
>  15         panic("BUG!"); \
>  16 } while (0)
>  17 #endif
>  18 #else
>  19 #define BUG() do { \
>  20         __builtin_trap(); \
>  21 } while (0)
>  22 #endif
>  23
>  24 #define HAVE_ARCH_BUG
>  25 #endif
>  26 #endif /* CONFIG_MMU */
>  27
>  28 #include <asm-generic/bug.h>
>  29
>  30 #endif
> 
> 
> 
> 
> Thanks.
> 


-- 
Chen Gang

Asianux Corporation


WARNING: multiple messages have this Message-ID (diff)
From: Chen Gang <gang.chen@asianux.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: "Catalin Marinas" <Catalin.Marinas@arm.com>,
	"Linux-sh list" <linux-sh@vger.kernel.org>,
	"Heiko Carstens" <heiko.carstens@de.ibm.com>,
	"paulus@samba.org" <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	"Michel Lespinasse" <walken@google.com>,
	"Hans-Christian Egtvedt" <egtvedt@samfundet.no>,
	Linux-Arch <linux-arch@vger.kernel.org>,
	linux-s390@vger.kernel.org,
	"Russell King - ARM Linux" <linux@arm.linux.org.uk>,
	uml-devel <user-mode-linux-devel@lists.sourceforge.net>,
	"Yoshinori Sato" <ysato@users.sourceforge.jp>,
	"Richard Weinberger" <richard@nod.at>,
	"Helge Deller" <deller@gmx.de>,
	"the arch/x86 maintainers" <x86@kernel.org>,
	"James E.J. Bottomley" <jejb@parisc-linux.org>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"Frederic Weisbecker" <fweisbec@gmail.com>,
	"Paul McKenney" <paulmck@linux.vnet.ibm.com>,
	"Håvard Skinnemoen" <hskinnemoen@gmail.com>,
	"Serge Hallyn" <serge.hallyn@canonical.com>,
	"Mike Frysinger" <vapier@gentoo.org>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Will Deacon" <will.deacon@arm.com>,
	"Jeff Dike" <jdike@addtoit.com>,
	"Akinobu Mita" <akinobu.mita@gmail.com>,
	uml-user <user-mode-linux-user@lists.sourceforge.net>,
	"uclinux-dist-devel@blackfin.uclinux.org"
	<uclinux-dist-devel@blackfin.uclinux.org>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"Parisc List" <linux-parisc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Richard Kuo" <rkuo@codeaurora.org>,
	"Paul Mundt" <lethal@linux-sh.org>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	linux-hexagon@vger.kernel.org,
	"Martin Schwidefsky" <schwidefsky@de.ibm.com>,
	linux390@de.ibm.com, "Andrew Morton" <akpm@linux-foundation.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"David Miller" <davem@davemloft.net>
Subject: Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.
Date: Fri, 24 May 2013 12:17:26 +0800	[thread overview]
Message-ID: <519EE9D6.9010707@asianux.com> (raw)
In-Reply-To: <519ECCCF.8090909@asianux.com>

On 05/24/2013 10:13 AM, Chen Gang wrote:
> On 05/23/2013 10:10 PM, Geert Uytterhoeven wrote:
>> On Thu, May 23, 2013 at 2:50 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>>>> On Thu, May 23, 2013 at 02:09:02PM +0200, Arnd Bergmann wrote:
>>>>>> On Thursday 23 May 2013, Russell King - ARM Linux wrote:
>>>>>>>> This is the problem you guys are missing - unreachable() means "we lose
>>>>>>>> control of the CPU at this point".
>>>>>>
>>>>>> I'm absolutely aware of this. Again, the current behaviour of doing nothing
>>>>>> at all isn't very different from undefined behavior when you get when you
>>>>>> get to the end of a function returning a pointer without a "return" statement,
>>>>>> or when you return from a function that has determined that it is not safe
>>>>>> to continue.
>>>>
>>>> Running off the end of a function like that is a different kettle of fish.
>>>> The execution path is still as the compiler intends - what isn't is that
>>>> the data returned is likely to be random trash.
>>>>
>>>> That's _quite_ different from the CPU starting to execute the contents
>>>> of a literal data pool.
>> I agree it's best to e.g. trap and reboot.
> 

In fact: if enable CONFIG_BUG, but not enable HAVE_ARCH_BUG, the
default implementation is:

 47 #ifndef HAVE_ARCH_BUG
 48 #define BUG() do { \
 49         printk("BUG: failure at %s:%d/%s()!\n", __FILE__, __LINE__, __func__); \
 50         panic("BUG!"); \
 51 } while (0)
 52 #endif

So if we delete CONFIG_BUG, the default implementation will be almost
like panic(),  and in panic() itself, also calls printk() !!

So...

:-)



> After read the arch/*/include/asm/bug.h,
> 
> It seems panic() is not suitable for NOMMU platforms (only m68k use it,
> also need CONFIG_BUG and CONFIG_SUN3 enabled).
> 
> And unreachable() is need followed with an asm inline instruction (arm,
> x86, powerpc mips...).
> 
> And __builtin_trap() is "the mechanism used may vary from release to
> release so should not rely on any particular implementation" (ref to
> "http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html", used by m68k,
> sparc, ia64).
> 
> I can not find any *trap*() and *unreachable*() in "include/asm-generic/"
> 
> I can not find any suitable implementation which 'generic' enough to add
> in "include/asm-generic/" (and in fact, CONFIG_BUG itself is not
> 'generic' enough to be in "include/asm-generic/").
> 
> 
> At last, I still suggest to delete CONFIG_BUG, so most of architectures
> can skip this issue firstly.
> 
> Then for specific architectures, also can get 3 benefits:
> 
> a. the related maintainers can implement it as their own willing (not
> need discus it with another platform maintainers again);
> 
> b. the related maintainers can free use the platform specific features
> (which can not be used in "include/asm-generic/");
> 
> c. the related maintainers are more familiar their own architectures
> demands and requirements.
> 
> 
> 
> ----------- arch/m68k/include/asm/bug.h --------------------------------
> 
>   1 #ifndef _M68K_BUG_H
>   2 #define _M68K_BUG_H
>   3
>   4 #ifdef CONFIG_MMU
>   5 #ifdef CONFIG_BUG
>   6 #ifdef CONFIG_DEBUG_BUGVERBOSE
>   7 #ifndef CONFIG_SUN3
>   8 #define BUG() do { \
>   9         printk("kernel BUG at %s:%d!\n", __FILE__, __LINE__); \
>  10         __builtin_trap(); \
>  11 } while (0)
>  12 #else
>  13 #define BUG() do { \
>  14         printk("kernel BUG at %s:%d!\n", __FILE__, __LINE__); \
>  15         panic("BUG!"); \
>  16 } while (0)
>  17 #endif
>  18 #else
>  19 #define BUG() do { \
>  20         __builtin_trap(); \
>  21 } while (0)
>  22 #endif
>  23
>  24 #define HAVE_ARCH_BUG
>  25 #endif
>  26 #endif /* CONFIG_MMU */
>  27
>  28 #include <asm-generic/bug.h>
>  29
>  30 #endif
> 
> 
> 
> 
> Thanks.
> 


-- 
Chen Gang

Asianux Corporation

WARNING: multiple messages have this Message-ID (diff)
From: gang.chen@asianux.com (Chen Gang)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.
Date: Fri, 24 May 2013 12:17:26 +0800	[thread overview]
Message-ID: <519EE9D6.9010707@asianux.com> (raw)
In-Reply-To: <519ECCCF.8090909@asianux.com>

On 05/24/2013 10:13 AM, Chen Gang wrote:
> On 05/23/2013 10:10 PM, Geert Uytterhoeven wrote:
>> On Thu, May 23, 2013 at 2:50 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>>>> On Thu, May 23, 2013 at 02:09:02PM +0200, Arnd Bergmann wrote:
>>>>>> On Thursday 23 May 2013, Russell King - ARM Linux wrote:
>>>>>>>> This is the problem you guys are missing - unreachable() means "we lose
>>>>>>>> control of the CPU at this point".
>>>>>>
>>>>>> I'm absolutely aware of this. Again, the current behaviour of doing nothing
>>>>>> at all isn't very different from undefined behavior when you get when you
>>>>>> get to the end of a function returning a pointer without a "return" statement,
>>>>>> or when you return from a function that has determined that it is not safe
>>>>>> to continue.
>>>>
>>>> Running off the end of a function like that is a different kettle of fish.
>>>> The execution path is still as the compiler intends - what isn't is that
>>>> the data returned is likely to be random trash.
>>>>
>>>> That's _quite_ different from the CPU starting to execute the contents
>>>> of a literal data pool.
>> I agree it's best to e.g. trap and reboot.
> 

In fact: if enable CONFIG_BUG, but not enable HAVE_ARCH_BUG, the
default implementation is:

 47 #ifndef HAVE_ARCH_BUG
 48 #define BUG() do { \
 49         printk("BUG: failure at %s:%d/%s()!\n", __FILE__, __LINE__, __func__); \
 50         panic("BUG!"); \
 51 } while (0)
 52 #endif

So if we delete CONFIG_BUG, the default implementation will be almost
like panic(),  and in panic() itself, also calls printk() !!

So...

:-)



> After read the arch/*/include/asm/bug.h,
> 
> It seems panic() is not suitable for NOMMU platforms (only m68k use it,
> also need CONFIG_BUG and CONFIG_SUN3 enabled).
> 
> And unreachable() is need followed with an asm inline instruction (arm,
> x86, powerpc mips...).
> 
> And __builtin_trap() is "the mechanism used may vary from release to
> release so should not rely on any particular implementation" (ref to
> "http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html", used by m68k,
> sparc, ia64).
> 
> I can not find any *trap*() and *unreachable*() in "include/asm-generic/"
> 
> I can not find any suitable implementation which 'generic' enough to add
> in "include/asm-generic/" (and in fact, CONFIG_BUG itself is not
> 'generic' enough to be in "include/asm-generic/").
> 
> 
> At last, I still suggest to delete CONFIG_BUG, so most of architectures
> can skip this issue firstly.
> 
> Then for specific architectures, also can get 3 benefits:
> 
> a. the related maintainers can implement it as their own willing (not
> need discus it with another platform maintainers again);
> 
> b. the related maintainers can free use the platform specific features
> (which can not be used in "include/asm-generic/");
> 
> c. the related maintainers are more familiar their own architectures
> demands and requirements.
> 
> 
> 
> ----------- arch/m68k/include/asm/bug.h --------------------------------
> 
>   1 #ifndef _M68K_BUG_H
>   2 #define _M68K_BUG_H
>   3
>   4 #ifdef CONFIG_MMU
>   5 #ifdef CONFIG_BUG
>   6 #ifdef CONFIG_DEBUG_BUGVERBOSE
>   7 #ifndef CONFIG_SUN3
>   8 #define BUG() do { \
>   9         printk("kernel BUG at %s:%d!\n", __FILE__, __LINE__); \
>  10         __builtin_trap(); \
>  11 } while (0)
>  12 #else
>  13 #define BUG() do { \
>  14         printk("kernel BUG at %s:%d!\n", __FILE__, __LINE__); \
>  15         panic("BUG!"); \
>  16 } while (0)
>  17 #endif
>  18 #else
>  19 #define BUG() do { \
>  20         __builtin_trap(); \
>  21 } while (0)
>  22 #endif
>  23
>  24 #define HAVE_ARCH_BUG
>  25 #endif
>  26 #endif /* CONFIG_MMU */
>  27
>  28 #include <asm-generic/bug.h>
>  29
>  30 #endif
> 
> 
> 
> 
> Thanks.
> 


-- 
Chen Gang

Asianux Corporation

  reply	other threads:[~2013-05-24  4:17 UTC|newest]

Thread overview: 127+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-23  7:57 [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it Chen Gang
2013-05-23  7:57 ` Chen Gang
2013-05-23  7:57 ` Chen Gang
2013-05-23  7:57 ` Chen Gang
2013-05-23  7:57 ` Chen Gang
2013-05-23  7:57 ` Chen Gang
2013-05-23  8:40 ` Geert Uytterhoeven
2013-05-23  8:40   ` Geert Uytterhoeven
2013-05-23  8:40   ` Geert Uytterhoeven
2013-05-23  8:40   ` Geert Uytterhoeven
2013-05-23  8:54   ` Arnd Bergmann
2013-05-23  8:54     ` Arnd Bergmann
2013-05-23  8:54     ` Arnd Bergmann
2013-05-23  8:54     ` Arnd Bergmann
     [not found]   ` <CAMuHMdU7QuzgmWCH145p8PVebBzPo8DBAvbY+0AZa2cmGXmRHw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-05-23  9:05     ` Russell King - ARM Linux
2013-05-23  9:05       ` Russell King - ARM Linux
2013-05-23  9:05       ` Russell King - ARM Linux
2013-05-23  9:05       ` Russell King - ARM Linux
2013-05-23  9:05       ` Russell King - ARM Linux
2013-05-23  9:12       ` Geert Uytterhoeven
2013-05-23  9:12         ` Geert Uytterhoeven
2013-05-23  9:12         ` Geert Uytterhoeven
2013-05-23  9:12         ` Geert Uytterhoeven
2013-05-23  9:39         ` Arnd Bergmann
2013-05-23  9:39           ` Arnd Bergmann
2013-05-23  9:39           ` Arnd Bergmann
2013-05-23  9:39           ` Arnd Bergmann
     [not found]           ` <201305231139.38233.arnd-r2nGTMty4D4@public.gmane.org>
2013-05-23 10:04             ` Russell King - ARM Linux
2013-05-23 10:04               ` Russell King - ARM Linux
2013-05-23 10:04               ` Russell King - ARM Linux
2013-05-23 10:04               ` Russell King - ARM Linux
2013-05-23 10:41               ` Chen Gang
2013-05-23 10:41                 ` Chen Gang
2013-05-23 10:41                 ` Chen Gang
2013-05-23 10:41                 ` Chen Gang
2013-05-23 10:59               ` Arnd Bergmann
2013-05-23 10:59                 ` Arnd Bergmann
2013-05-23 10:59                 ` Arnd Bergmann
2013-05-23 10:59                 ` Arnd Bergmann
     [not found]                 ` <201305231259.43750.arnd-r2nGTMty4D4@public.gmane.org>
2013-05-23 11:19                   ` Chen Gang
2013-05-23 11:19                     ` Chen Gang
2013-05-23 11:19                     ` Chen Gang
2013-05-23 11:19                     ` Chen Gang
2013-05-23 11:19                     ` Chen Gang
2013-05-23 11:24                 ` Russell King - ARM Linux
2013-05-23 11:24                   ` Russell King - ARM Linux
2013-05-23 11:24                   ` Russell King - ARM Linux
2013-05-23 11:24                   ` Russell King - ARM Linux
     [not found]                   ` <20130523112401.GO18614-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2013-05-23 12:09                     ` Arnd Bergmann
2013-05-23 12:09                       ` Arnd Bergmann
2013-05-23 12:09                       ` Arnd Bergmann
2013-05-23 12:09                       ` Arnd Bergmann
2013-05-23 12:50                       ` Russell King - ARM Linux
2013-05-23 12:50                         ` Russell King - ARM Linux
2013-05-23 12:50                         ` Russell King - ARM Linux
2013-05-23 12:50                         ` Russell King - ARM Linux
2013-05-23 14:10                         ` Geert Uytterhoeven
2013-05-23 14:10                           ` Geert Uytterhoeven
2013-05-23 14:10                           ` Geert Uytterhoeven
2013-05-23 14:10                           ` Geert Uytterhoeven
2013-05-24  2:13                           ` Chen Gang
2013-05-24  2:13                             ` Chen Gang
2013-05-24  2:13                             ` Chen Gang
2013-05-24  2:13                             ` Chen Gang
2013-05-24  4:17                             ` Chen Gang [this message]
2013-05-24  4:17                               ` Chen Gang
2013-05-24  4:17                               ` Chen Gang
2013-05-24  4:17                               ` Chen Gang
2013-05-26  4:43                               ` [PATCH v2] arch: configuration issue, random return value when disable 'CONFIG_BUG' Chen Gang
2013-05-26  4:43                                 ` Chen Gang
2013-05-26  4:43                                 ` Chen Gang
2013-05-26  4:43                                 ` Chen Gang
2013-05-28  8:19               ` [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it Ingo Molnar
2013-05-28  8:19                 ` Ingo Molnar
2013-05-28  8:19                 ` Ingo Molnar
2013-05-28  8:19                 ` Ingo Molnar
2013-05-28  8:19                 ` Ingo Molnar
2013-05-28  8:19                 ` Ingo Molnar
2013-05-28  8:19                 ` Ingo Molnar
2013-05-28 10:25                 ` Chen Gang
2013-05-28 10:25                   ` Chen Gang
2013-05-28 10:25                   ` Chen Gang
2013-05-28 10:25                   ` Chen Gang
2013-05-28 10:25                   ` Chen Gang
2013-05-28 14:49                 ` Arnd Bergmann
2013-05-28 14:49                   ` Arnd Bergmann
2013-05-28 14:49                   ` Arnd Bergmann
2013-05-28 14:49                   ` Arnd Bergmann
2013-05-28 14:49                   ` Arnd Bergmann
     [not found]                 ` <20130528081910.GA29557-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-05-28 14:55                   ` H. Peter Anvin
2013-05-28 14:55                     ` H. Peter Anvin
2013-05-28 14:55                     ` H. Peter Anvin
2013-05-28 14:55                     ` H. Peter Anvin
2013-05-28 14:55                     ` H. Peter Anvin
2013-05-28 15:43                     ` Arnd Bergmann
2013-05-28 15:43                       ` Arnd Bergmann
2013-05-28 15:43                       ` Arnd Bergmann
2013-05-28 15:43                       ` Arnd Bergmann
2013-05-28 15:43                       ` Arnd Bergmann
     [not found]                       ` <201305281743.52649.arnd-r2nGTMty4D4@public.gmane.org>
2013-05-28 16:06                         ` H. Peter Anvin
2013-05-28 16:06                           ` H. Peter Anvin
2013-05-28 16:06                           ` H. Peter Anvin
2013-05-28 16:06                           ` H. Peter Anvin
2013-05-28 16:06                           ` H. Peter Anvin
     [not found]                           ` <51A4D618.3080208-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>
2013-05-28 17:20                             ` Arnd Bergmann
2013-05-28 17:20                               ` Arnd Bergmann
2013-05-28 17:20                               ` Arnd Bergmann
2013-05-28 17:20                               ` Arnd Bergmann
2013-05-28 17:20                               ` Arnd Bergmann
2013-05-23 10:09           ` Eric W. Biederman
2013-05-23 10:09             ` Eric W. Biederman
2013-05-23 10:09             ` Eric W. Biederman
2013-05-23 10:09             ` Eric W. Biederman
     [not found]             ` <878v369fdd.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2013-05-23 10:29               ` Russell King - ARM Linux
2013-05-23 10:29                 ` Russell King - ARM Linux
2013-05-23 10:29                 ` Russell King - ARM Linux
2013-05-23 10:29                 ` Russell King - ARM Linux
2013-05-23 10:29                 ` Russell King - ARM Linux
2013-05-23 10:29                 ` Russell King - ARM Linux
2013-05-23 10:05         ` Chen Gang
2013-05-23 10:05           ` Chen Gang
2013-05-23 10:05           ` Chen Gang
2013-05-23 10:05           ` Chen Gang
2013-05-24  5:59 ` Eric W. Biederman
2013-05-24  5:59   ` Eric W. Biederman
2013-05-24  5:59   ` Eric W. Biederman
2013-05-24  5:59   ` Eric W. Biederman

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=519EE9D6.9010707@asianux.com \
    --to=gang.chen@asianux.com \
    --cc=Catalin.Marinas@arm.com \
    --cc=deller@gmx.de \
    --cc=egtvedt@samfundet.no \
    --cc=fweisbec@gmail.com \
    --cc=geert@linux-m68k.org \
    --cc=heiko.carstens@de.ibm.com \
    --cc=hpa@zytor.com \
    --cc=hskinnemoen@gmail.com \
    --cc=jejb@parisc-linux.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=mingo@redhat.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=paulus@samba.org \
    --cc=richard@nod.at \
    --cc=user-mode-linux-devel@lists.sourceforge.net \
    --cc=walken@google.com \
    --cc=x86@kernel.org \
    --cc=ysato@users.sourceforge.jp \
    /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: link
Be 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.