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 10:13:35 +0800 [thread overview]
Message-ID: <519ECCCF.8090909@asianux.com> (raw)
In-Reply-To: <CAMuHMdUzcBuDupe4Fa6XieziGPMpPKC_k8X8gUUmDvLJ+Fe=Hg@mail.gmail.com>
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.
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 10:13:35 +0800 [thread overview]
Message-ID: <519ECCCF.8090909@asianux.com> (raw)
In-Reply-To: <CAMuHMdUzcBuDupe4Fa6XieziGPMpPKC_k8X8gUUmDvLJ+Fe=Hg@mail.gmail.com>
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.
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
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
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 10:13:35 +0800 [thread overview]
Message-ID: <519ECCCF.8090909@asianux.com> (raw)
In-Reply-To: <CAMuHMdUzcBuDupe4Fa6XieziGPMpPKC_k8X8gUUmDvLJ+Fe=Hg@mail.gmail.com>
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.
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 10:13:35 +0800 [thread overview]
Message-ID: <519ECCCF.8090909@asianux.com> (raw)
In-Reply-To: <CAMuHMdUzcBuDupe4Fa6XieziGPMpPKC_k8X8gUUmDvLJ+Fe=Hg@mail.gmail.com>
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.
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
next prev parent reply other threads:[~2013-05-24 2:13 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 [this message]
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
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=519ECCCF.8090909@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.