[PATCH 1/1] ARM: thumb: Have the machine name indicate operation in thumb mode.

[PATCH 1/1] ARM: thumb: Have the machine name indicate operation in thumb mode.

[Vadim Bendebury]

This is a cosmetic change, adding a '_thumb' prefix to the
'Hardware' line in /proc/cpuinfo. Tested as follows:

localhost ~ # dmesg | grep thumb
[    0.000000] Machine: kaen_thumb
localhost ~ # grep '^Hardware' /proc/cpuinfo
Hardware        : kaen_thumb
localhost ~ #

Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
---
 arch/arm/include/asm/mach/arch.h |    8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/arch/arm/include/asm/mach/arch.h b/arch/arm/include/asm/mach/arch.h
index bf13b81..c7445a5 100644
--- a/arch/arm/include/asm/mach/arch.h
+++ b/arch/arm/include/asm/mach/arch.h
@@ -51,12 +51,18 @@ extern struct machine_desc *machine_desc;
  * Set of macros to define architecture features.  This is built into
  * a table by the linker.
  */
+#ifdef CONFIG_THUMB2_KERNEL
+#define NAME_SUFFIX	"_thumb"
+#else
+#define NAME_SUFFIX	""
+#endif
+
 #define MACHINE_START(_type,_name)			\
 static const struct machine_desc __mach_desc_##_type	\
  __used							\
  __attribute__((__section__(".arch.info.init"))) = {	\
 	.nr		= MACH_TYPE_##_type,		\
-	.name		= _name,
+	.name		= _name NAME_SUFFIX,
 
 #define MACHINE_END				\
 };
-- 
1.7.3.1

[PATCH 1/1] ARM: thumb: Have the machine name indicate operation in thumb mode.

[Catalin Marinas]

On 13 May 2011 20:53, Vadim Bendebury <vbendeb@google.com> wrote:
> This is a cosmetic change, adding a '_thumb' prefix to the
> 'Hardware' line in /proc/cpuinfo. Tested as follows:
>
> localhost ~ # dmesg | grep thumb
> [ ? ?0.000000] Machine: kaen_thumb
> localhost ~ # grep '^Hardware' /proc/cpuinfo
> Hardware ? ? ? ?: kaen_thumb
> localhost ~ #

Would this break any script parsing this file?

BTW, why do you need it? You could include the .config into the kernel
and read it via /proc.

-- 
Catalin

[PATCH 1/1] ARM: thumb: Have the machine name indicate operation in thumb mode.

[Russell King - ARM Linux]

On Sat, May 14, 2011 at 10:59:14AM +0100, Catalin Marinas wrote:
> On 13 May 2011 20:53, Vadim Bendebury <vbendeb@google.com> wrote:
> > This is a cosmetic change, adding a '_thumb' prefix to the
> > 'Hardware' line in /proc/cpuinfo. Tested as follows:
> >
> > localhost ~ # dmesg | grep thumb
> > [ ? ?0.000000] Machine: kaen_thumb
> > localhost ~ # grep '^Hardware' /proc/cpuinfo
> > Hardware ? ? ? ?: kaen_thumb
> > localhost ~ #
> 
> Would this break any script parsing this file?
> 
> BTW, why do you need it? You could include the .config into the kernel
> and read it via /proc.

Whether the kernel is built T2 or ARM doesn't change the userland API
either, so there's no real need for userland to know how the kernel
was built.

The only thing which is affected by it are kernel modules, but then we
have an established way to sort out incompatible kernel modules already.

[PATCH 1/1] ARM: thumb: Have the machine name indicate operation in thumb mode.

[Dave Martin]

On Sat, May 14, 2011 at 11:02:32AM +0100, Russell King - ARM Linux wrote:
> On Sat, May 14, 2011 at 10:59:14AM +0100, Catalin Marinas wrote:
> > On 13 May 2011 20:53, Vadim Bendebury <vbendeb@google.com> wrote:
> > > This is a cosmetic change, adding a '_thumb' prefix to the
> > > 'Hardware' line in /proc/cpuinfo. Tested as follows:
> > >
> > > localhost ~ # dmesg | grep thumb
> > > [ ? ?0.000000] Machine: kaen_thumb
> > > localhost ~ # grep '^Hardware' /proc/cpuinfo
> > > Hardware ? ? ? ?: kaen_thumb
> > > localhost ~ #
> > 
> > Would this break any script parsing this file?
> > 
> > BTW, why do you need it? You could include the .config into the kernel
> > and read it via /proc.
> 
> Whether the kernel is built T2 or ARM doesn't change the userland API
> either, so there's no real need for userland to know how the kernel
> was built.
> 
> The only thing which is affected by it are kernel modules, but then we
> have an established way to sort out incompatible kernel modules already.

One corollary to that is that _if_ there's any reason why userland needs to 
know what instruction set the kernel was built with, then we're probably
doing something wrong somewhere...

In any case, shoehorning this information into the hardware platform name
seems a bit strange since this is really nothing to do with the hardware.

Vadim, can you explain why you think this information is needed?  If the
need is real, perhaps there's a better way to address it.

Cheers
---Dave

[PATCH 1/1] ARM: thumb: Have the machine name indicate operation in thumb mode.

[Nicolas Pitre]

On Mon, 16 May 2011, Dave Martin wrote:

> On Sat, May 14, 2011 at 11:02:32AM +0100, Russell King - ARM Linux wrote:
> > On Sat, May 14, 2011 at 10:59:14AM +0100, Catalin Marinas wrote:
> > > On 13 May 2011 20:53, Vadim Bendebury <vbendeb@google.com> wrote:
> > > > This is a cosmetic change, adding a '_thumb' prefix to the
> > > > 'Hardware' line in /proc/cpuinfo. Tested as follows:
> > > >
> > > > localhost ~ # dmesg | grep thumb
> > > > [ ? ?0.000000] Machine: kaen_thumb
> > > > localhost ~ # grep '^Hardware' /proc/cpuinfo
> > > > Hardware ? ? ? ?: kaen_thumb
> > > > localhost ~ #
> > > 
> > > Would this break any script parsing this file?
> > > 
> > > BTW, why do you need it? You could include the .config into the kernel
> > > and read it via /proc.
> > 
> > Whether the kernel is built T2 or ARM doesn't change the userland API
> > either, so there's no real need for userland to know how the kernel
> > was built.
> > 
> > The only thing which is affected by it are kernel modules, but then we
> > have an established way to sort out incompatible kernel modules already.
> 
> One corollary to that is that _if_ there's any reason why userland needs to 
> know what instruction set the kernel was built with, then we're probably
> doing something wrong somewhere...
> 
> In any case, shoehorning this information into the hardware platform name
> seems a bit strange since this is really nothing to do with the hardware.
> 
> Vadim, can you explain why you think this information is needed?  If the
> need is real, perhaps there's a better way to address it.

I think this can be useful to know how the kernel was compiled for bug 
tracking purposes, just like we record the Git commit ID of the checked 
out source tree, the gcc version, the build date, etc.  Which pretty 
much indicates that the thumbness of the kernel should probably be 
stored in the kernel banner not the platform name.


Nicolas

[PATCH 1/1] ARM: thumb: Have the machine name indicate operation in thumb mode.

[Dave Martin]

On Mon, May 16, 2011 at 10:32:16AM -0400, Nicolas Pitre wrote:
> On Mon, 16 May 2011, Dave Martin wrote:
> 
> > On Sat, May 14, 2011 at 11:02:32AM +0100, Russell King - ARM Linux wrote:
> > > On Sat, May 14, 2011 at 10:59:14AM +0100, Catalin Marinas wrote:
> > > > On 13 May 2011 20:53, Vadim Bendebury <vbendeb@google.com> wrote:
> > > > > This is a cosmetic change, adding a '_thumb' prefix to the
> > > > > 'Hardware' line in /proc/cpuinfo. Tested as follows:
> > > > >
> > > > > localhost ~ # dmesg | grep thumb
> > > > > [ ? ?0.000000] Machine: kaen_thumb
> > > > > localhost ~ # grep '^Hardware' /proc/cpuinfo
> > > > > Hardware ? ? ? ?: kaen_thumb
> > > > > localhost ~ #
> > > > 
> > > > Would this break any script parsing this file?
> > > > 
> > > > BTW, why do you need it? You could include the .config into the kernel
> > > > and read it via /proc.
> > > 
> > > Whether the kernel is built T2 or ARM doesn't change the userland API
> > > either, so there's no real need for userland to know how the kernel
> > > was built.
> > > 
> > > The only thing which is affected by it are kernel modules, but then we
> > > have an established way to sort out incompatible kernel modules already.
> > 
> > One corollary to that is that _if_ there's any reason why userland needs to 
> > know what instruction set the kernel was built with, then we're probably
> > doing something wrong somewhere...
> > 
> > In any case, shoehorning this information into the hardware platform name
> > seems a bit strange since this is really nothing to do with the hardware.
> > 
> > Vadim, can you explain why you think this information is needed?  If the
> > need is real, perhaps there's a better way to address it.
> 
> I think this can be useful to know how the kernel was compiled for bug 
> tracking purposes, just like we record the Git commit ID of the checked 
> out source tree, the gcc version, the build date, etc.  Which pretty 
> much indicates that the thumbness of the kernel should probably be 
> stored in the kernel banner not the platform name.

That seems a reasonable approach to me.

---Dave

[PATCH 1/1] ARM: thumb: Have the machine name indicate operation in thumb mode.

[Vadim Bendebury (вб)]

On Mon, May 16, 2011 at 7:43 AM, Dave Martin <dave.martin@linaro.org> wrote:
> On Mon, May 16, 2011 at 10:32:16AM -0400, Nicolas Pitre wrote:
>> On Mon, 16 May 2011, Dave Martin wrote:
>>
>> > On Sat, May 14, 2011 at 11:02:32AM +0100, Russell King - ARM Linux wrote:
>> > > On Sat, May 14, 2011 at 10:59:14AM +0100, Catalin Marinas wrote:
>> > > > On 13 May 2011 20:53, Vadim Bendebury <vbendeb@google.com> wrote:
>> > > > > This is a cosmetic change, adding a '_thumb' prefix to the
>> > > > > 'Hardware' line in /proc/cpuinfo. Tested as follows:
>> > > > >
>> > > > > localhost ~ # dmesg | grep thumb
>> > > > > [ ? ?0.000000] Machine: kaen_thumb
>> > > > > localhost ~ # grep '^Hardware' /proc/cpuinfo
>> > > > > Hardware ? ? ? ?: kaen_thumb
>> > > > > localhost ~ #
>> > > >
>> > > > Would this break any script parsing this file?
>> > > >
>> > > > BTW, why do you need it? You could include the .config into the kernel
>> > > > and read it via /proc.
>> > >
>> > > Whether the kernel is built T2 or ARM doesn't change the userland API
>> > > either, so there's no real need for userland to know how the kernel
>> > > was built.
>> > >
>> > > The only thing which is affected by it are kernel modules, but then we
>> > > have an established way to sort out incompatible kernel modules already.
>> >
>> > One corollary to that is that _if_ there's any reason why userland needs to
>> > know what instruction set the kernel was built with, then we're probably
>> > doing something wrong somewhere...
>> >
>> > In any case, shoehorning this information into the hardware platform name
>> > seems a bit strange since this is really nothing to do with the hardware.
>> >
>> > Vadim, can you explain why you think this information is needed? ?If the
>> > need is real, perhaps there's a better way to address it.
>>
>> I think this can be useful to know how the kernel was compiled for bug
>> tracking purposes, just like we record the Git commit ID of the checked
>> out source tree, the gcc version, the build date, etc. ?Which pretty
>> much indicates that the thumbness of the kernel should probably be
>> stored in the kernel banner not the platform name.
>
> That seems a reasonable approach to me.
>

guys, thank you for your comments. Indeed, this is meant to be just a
convenience to allow to quickly tell what kind of kernel a system is
running, comes handy when there are many systems around with
differently compiled kernels.

So, would it be acceptable if I move this information into the kernel
banner (namely, add it to the machine hardware name part of the output
included in 'uname -m' and 'uname -a')?

cheers,
/vb




> ---Dave
>

[PATCH 1/1] ARM: thumb: Have the machine name indicate operation in thumb mode.

[Nicolas Pitre]

On Wed, 18 May 2011, Vadim Bendebury (??) wrote:

> On Mon, May 16, 2011 at 7:43 AM, Dave Martin <dave.martin@linaro.org> wrote:
> >On Mon, May 16, 2011 at 10:32:16AM -0400, Nicolas Pitre wrote:
> >> I think this can be useful to know how the kernel was compiled for bug
> >> tracking purposes, just like we record the Git commit ID of the checked
> >> out source tree, the gcc version, the build date, etc. ?Which pretty
> >> much indicates that the thumbness of the kernel should probably be
> >> stored in the kernel banner not the platform name.
> >
> > That seems a reasonable approach to me.
> >
> 
> guys, thank you for your comments. Indeed, this is meant to be just a
> convenience to allow to quickly tell what kind of kernel a system is
> running, comes handy when there are many systems around with
> differently compiled kernels.
> 
> So, would it be acceptable if I move this information into the kernel
> banner (namely, add it to the machine hardware name part of the output
> included in 'uname -m' and 'uname -a')?

Yes, I think that would be the most sensible place.  Looking at 
scripts/mkcompile_h which is used to create include/generated/compile.h, 
it appears that $CONFIG_FLAGS would be the most appropriate place for 
this, however it is not currently set up to allow architecture specific 
flags to be passed in.


Nicolas

[PATCH 1/1] ARM: thumb: Have the machine name indicate operation in thumb mode.

[Russell King - ARM Linux]

On Wed, May 18, 2011 at 06:27:56PM -0400, Nicolas Pitre wrote:
> On Wed, 18 May 2011, Vadim Bendebury (??) wrote:
> 
> > On Mon, May 16, 2011 at 7:43 AM, Dave Martin <dave.martin@linaro.org> wrote:
> > >On Mon, May 16, 2011 at 10:32:16AM -0400, Nicolas Pitre wrote:
> > >> I think this can be useful to know how the kernel was compiled for bug
> > >> tracking purposes, just like we record the Git commit ID of the checked
> > >> out source tree, the gcc version, the build date, etc. ?Which pretty
> > >> much indicates that the thumbness of the kernel should probably be
> > >> stored in the kernel banner not the platform name.
> > >
> > > That seems a reasonable approach to me.
> > >
> > 
> > guys, thank you for your comments. Indeed, this is meant to be just a
> > convenience to allow to quickly tell what kind of kernel a system is
> > running, comes handy when there are many systems around with
> > differently compiled kernels.
> > 
> > So, would it be acceptable if I move this information into the kernel
> > banner (namely, add it to the machine hardware name part of the output
> > included in 'uname -m' and 'uname -a')?
> 
> Yes, I think that would be the most sensible place.  Looking at 
> scripts/mkcompile_h which is used to create include/generated/compile.h, 
> it appears that $CONFIG_FLAGS would be the most appropriate place for 
> this, however it is not currently set up to allow architecture specific 
> flags to be passed in.

We already have a way of adding stuff for bug tracking purposes.  The
"Internal error" line is perpended with 'PREEMPT' or 'SMP' depending
on what build options were enabled.  We just need to do the same with
T2.  IOW, something like this:

diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index 3b54ad1..78d7714 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -225,6 +225,11 @@ void show_stack(struct task_struct *tsk, unsigned long *sp)
 #else
 #define S_SMP ""
 #endif
+#ifdef CONFIG_THUMB2_KERNEL
+#define S_ISA " T2"
+#else
+#define S_ISA " ARM"
+#endif
 
 static int __die(const char *str, int err, struct thread_info *thread, struct pt_regs *regs)
 {
@@ -232,8 +237,8 @@ static int __die(const char *str, int err, struct thread_info *thread, struct pt
 	static int die_counter;
 	int ret;
 
-	printk(KERN_EMERG "Internal error: %s: %x [#%d]" S_PREEMPT S_SMP "\n",
-	       str, err, ++die_counter);
+	printk(KERN_EMERG "Internal error: %s: %x [#%d]" S_PREEMPT S_SMP
+	       S_ISA "\n", str, err, ++die_counter);
 	sysfs_printk_last_file();
 
 	/* trap and error numbers are mostly meaningless on ARM */

[PATCH 1/1] ARM: thumb: Have the machine name indicate operation in thumb mode.

[Nicolas Pitre]

On Wed, 18 May 2011, Russell King - ARM Linux wrote:

> On Wed, May 18, 2011 at 06:27:56PM -0400, Nicolas Pitre wrote:
> > On Wed, 18 May 2011, Vadim Bendebury (??) wrote:
> > 
> > > On Mon, May 16, 2011 at 7:43 AM, Dave Martin <dave.martin@linaro.org> wrote:
> > > >On Mon, May 16, 2011 at 10:32:16AM -0400, Nicolas Pitre wrote:
> > > >> I think this can be useful to know how the kernel was compiled for bug
> > > >> tracking purposes, just like we record the Git commit ID of the checked
> > > >> out source tree, the gcc version, the build date, etc. ?Which pretty
> > > >> much indicates that the thumbness of the kernel should probably be
> > > >> stored in the kernel banner not the platform name.
> > > >
> > > > That seems a reasonable approach to me.
> > > >
> > > 
> > > guys, thank you for your comments. Indeed, this is meant to be just a
> > > convenience to allow to quickly tell what kind of kernel a system is
> > > running, comes handy when there are many systems around with
> > > differently compiled kernels.
> > > 
> > > So, would it be acceptable if I move this information into the kernel
> > > banner (namely, add it to the machine hardware name part of the output
> > > included in 'uname -m' and 'uname -a')?
> > 
> > Yes, I think that would be the most sensible place.  Looking at 
> > scripts/mkcompile_h which is used to create include/generated/compile.h, 
> > it appears that $CONFIG_FLAGS would be the most appropriate place for 
> > this, however it is not currently set up to allow architecture specific 
> > flags to be passed in.
> 
> We already have a way of adding stuff for bug tracking purposes.  The
> "Internal error" line is perpended with 'PREEMPT' or 'SMP' depending
> on what build options were enabled.  We just need to do the same with
> T2.  IOW, something like this:
[...]

This is indeed useful if the kernel oopses.  However this doesn't help 
for those cases where the kernel doesn't crash but still exhibits 
unexpected behaviors.  Having the thumbness of the kernel also displayed 
in dmesg and uname -a would also be good to have.


Nicolas

[PATCH 1/1] ARM: thumb: Have the machine name indicate operation in thumb mode.

[Russell King - ARM Linux]

On Wed, May 18, 2011 at 06:49:16PM -0400, Nicolas Pitre wrote:
> On Wed, 18 May 2011, Russell King - ARM Linux wrote:
> > We already have a way of adding stuff for bug tracking purposes.  The
> > "Internal error" line is perpended with 'PREEMPT' or 'SMP' depending
> > on what build options were enabled.  We just need to do the same with
> > T2.  IOW, something like this:
> [...]
> 
> This is indeed useful if the kernel oopses.  However this doesn't help 
> for those cases where the kernel doesn't crash but still exhibits 
> unexpected behaviors.  Having the thumbness of the kernel also displayed 
> in dmesg and uname -a would also be good to have.

In which case I think we'll have to talk to kbuild people to get
mkcompile_h modified.  Also maybe asking what other architectures
do for this kind of problem may be a good idea - especially before
we start abusing and hacking stuff like the hardware name.

[PATCH 1/1] ARM: thumb: Have the machine name indicate operation in thumb mode.

[Russell King - ARM Linux]

On Wed, May 25, 2011 at 03:08:05PM -0700, Vadim Bendebury (??) wrote:
> On Wed, May 18, 2011 at 3:57 PM, Russell King - ARM Linux <
> linux at arm.linux.org.uk> wrote:
> > In which case I think we'll have to talk to kbuild people to get
> > mkcompile_h modified.  Also maybe asking what other architectures
> > do for this kind of problem may be a good idea - especially before
> > we start abusing and hacking stuff like the hardware name.
> 
> So, what would be an equivalent in other architectures to ask about - it
> seems that the ability to run in Thumb/ARM mode is fairly unique for ARM.

What about 32-bit vs 64-bit x86 ?

> Consulting /boot/config file is not reliable: in my own setup I can netboot
> either thumb or ARM kernel without changing the root file system contents. I
> agree though that changing the hardware name is not the best way to do this
> either.
> 
> I could look into adding 'thumb' to any element of the uname output, or as a
> watered down version - just add a line to dmesg output?

The thing that I worry about is that userspace will start using this
information inappropriately.  Whether the kernel is built as T2 or ARM
is really only a matter for the kernel itself (and people debugging the
kernel), rather than random userspace programs.

Maybe a way forward would be to produce a patch for mkcompile_h, post it
to here, kbuild people and LKML and see what response is forthcoming.

[PATCH 1/1] ARM: thumb: Have the machine name indicate operation in thumb mode.

[Dave Martin]

On Thu, May 26, 2011 at 02:01:04PM +0100, Russell King - ARM Linux wrote:
> On Wed, May 25, 2011 at 03:08:05PM -0700, Vadim Bendebury (??) wrote:
> > On Wed, May 18, 2011 at 3:57 PM, Russell King - ARM Linux <
> > linux at arm.linux.org.uk> wrote:
> > > In which case I think we'll have to talk to kbuild people to get
> > > mkcompile_h modified.  Also maybe asking what other architectures
> > > do for this kind of problem may be a good idea - especially before
> > > we start abusing and hacking stuff like the hardware name.
> > 
> > So, what would be an equivalent in other architectures to ask about - it
> > seems that the ability to run in Thumb/ARM mode is fairly unique for ARM.
> 
> What about 32-bit vs 64-bit x86 ?

Thumb seems different because is is irrelevant to the kernel/user ABI
(or, if it's not irrelevant, we have a bug somewhere...)

Documenting what ISA the kernel was built with is therefore similar to
documenting what optimisation options were used -- i.e., it's interesting
and occasionally useful for humans, but not something software should
normally be querying or care about in any way.

> > Consulting /boot/config file is not reliable: in my own setup I can netboot
> > either thumb or ARM kernel without changing the root file system contents. I
> > agree though that changing the hardware name is not the best way to do this
> > either.
> > 
> > I could look into adding 'thumb' to any element of the uname output, or as a
> > watered down version - just add a line to dmesg output?
> 
> The thing that I worry about is that userspace will start using this
> information inappropriately.  Whether the kernel is built as T2 or ARM
> is really only a matter for the kernel itself (and people debugging the
> kernel), rather than random userspace programs.

Agreed

> 
> Maybe a way forward would be to produce a patch for mkcompile_h, post it
> to here, kbuild people and LKML and see what response is forthcoming.
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 1/1] ARM: thumb: Have the machine name indicate operation in thumb mode.

[Russell King - ARM Linux]

On Thu, May 26, 2011 at 02:56:04PM +0100, Dave Martin wrote:
> On Thu, May 26, 2011 at 02:01:04PM +0100, Russell King - ARM Linux wrote:
> > On Wed, May 25, 2011 at 03:08:05PM -0700, Vadim Bendebury (??) wrote:
> > > On Wed, May 18, 2011 at 3:57 PM, Russell King - ARM Linux <
> > > linux at arm.linux.org.uk> wrote:
> > > > In which case I think we'll have to talk to kbuild people to get
> > > > mkcompile_h modified.  Also maybe asking what other architectures
> > > > do for this kind of problem may be a good idea - especially before
> > > > we start abusing and hacking stuff like the hardware name.
> > > 
> > > So, what would be an equivalent in other architectures to ask about - it
> > > seems that the ability to run in Thumb/ARM mode is fairly unique for ARM.
> > 
> > What about 32-bit vs 64-bit x86 ?
> 
> Thumb seems different because is is irrelevant to the kernel/user ABI
> (or, if it's not irrelevant, we have a bug somewhere...)
> 
> Documenting what ISA the kernel was built with is therefore similar to
> documenting what optimisation options were used -- i.e., it's interesting
> and occasionally useful for humans, but not something software should
> normally be querying or care about in any way.

In which case its a bit like exposing whether the kernel was built with
or without frame pointers, or which -O level, which compiler flags, etc.

I think its best therefore that it remains in the kernel config along
with all the other 'optimisation' settings.

We don't even need to print it in the oops report because that already
tells us what ISA we were executing as - and from that and the Code: line
we can imply the kernel build ISA.

[PATCH 1/1] ARM: thumb: Have the machine name indicate operation in thumb mode.

[Dave Martin]

On Wed, May 18, 2011 at 11:33:19PM +0100, Russell King - ARM Linux wrote:

[...]

> We already have a way of adding stuff for bug tracking purposes.  The
> "Internal error" line is perpended with 'PREEMPT' or 'SMP' depending
> on what build options were enabled.  We just need to do the same with
> T2.  IOW, something like this:
> 
> diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
> index 3b54ad1..78d7714 100644
> --- a/arch/arm/kernel/traps.c
> +++ b/arch/arm/kernel/traps.c
> @@ -225,6 +225,11 @@ void show_stack(struct task_struct *tsk, unsigned long *sp)
>  #else
>  #define S_SMP ""
>  #endif
> +#ifdef CONFIG_THUMB2_KERNEL
> +#define S_ISA " T2"

Just for consistency, can I suggest that if this is implemented, we
make the string " thumb2"? (upper case optional)  This matches what
we now put in MODULE_ARCH_VERMAGIC, as well as being closer to the
CONFIG_ name.

Cheers
---Dave

[PATCH 1/1] ARM: thumb: Have the machine name indicate operation in thumb mode.

[Vadim Bendebury]

This is a cosmetic change, adding a '_thumb' prefix to the
'Hardware' line in /proc/cpuinfo. Tested as follows:

localhost ~ # dmesg | grep thumb
[    0.000000] Machine: kaen_thumb
localhost ~ # grep '^Hardware' /proc/cpuinfo
Hardware        : kaen_thumb
localhost ~ #

Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
---
 arch/arm/include/asm/mach/arch.h |    8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/arch/arm/include/asm/mach/arch.h b/arch/arm/include/asm/mach/arch.h
index bf13b81..c7445a5 100644
--- a/arch/arm/include/asm/mach/arch.h
+++ b/arch/arm/include/asm/mach/arch.h
@@ -51,12 +51,18 @@ extern struct machine_desc *machine_desc;
  * Set of macros to define architecture features.  This is built into
  * a table by the linker.
  */
+#ifdef CONFIG_THUMB2_KERNEL
+#define NAME_SUFFIX	"_thumb"
+#else
+#define NAME_SUFFIX	""
+#endif
+
 #define MACHINE_START(_type,_name)			\
 static const struct machine_desc __mach_desc_##_type	\
  __used							\
  __attribute__((__section__(".arch.info.init"))) = {	\
 	.nr		= MACH_TYPE_##_type,		\
-	.name		= _name,
+	.name		= _name NAME_SUFFIX,
 
 #define MACHINE_END				\
 };
-- 
1.7.3.1