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

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 <redacted>
---
 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

On 13 May 2011 20:53, Vadim Bendebury [off-list ref] 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

On Sat, May 14, 2011 at 10:59:14AM +0100, Catalin Marinas wrote:

On 13 May 2011 20:53, Vadim Bendebury [off-list ref] wrote:

quoted

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.

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:

quoted

On 13 May 2011 20:53, Vadim Bendebury [off-list ref] wrote:

quoted

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

On Mon, 16 May 2011, Dave Martin wrote:

On Sat, May 14, 2011 at 11:02:32AM +0100, Russell King - ARM Linux wrote:

quoted

On Sat, May 14, 2011 at 10:59:14AM +0100, Catalin Marinas wrote:

quoted

On 13 May 2011 20:53, Vadim Bendebury [off-list ref] wrote:

quoted

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

On Mon, May 16, 2011 at 10:32:16AM -0400, Nicolas Pitre wrote:

On Mon, 16 May 2011, Dave Martin wrote:

quoted

On Sat, May 14, 2011 at 11:02:32AM +0100, Russell King - ARM Linux wrote:

quoted

On Sat, May 14, 2011 at 10:59:14AM +0100, Catalin Marinas wrote:

quoted

On 13 May 2011 20:53, Vadim Bendebury [off-list ref] wrote:

quoted

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

On Mon, May 16, 2011 at 7:43 AM, Dave Martin [off-list ref] wrote:

On Mon, May 16, 2011 at 10:32:16AM -0400, Nicolas Pitre wrote:

quoted

On Mon, 16 May 2011, Dave Martin wrote:

quoted

On Sat, May 14, 2011 at 11:02:32AM +0100, Russell King - ARM Linux wrote:

quoted

On Sat, May 14, 2011 at 10:59:14AM +0100, Catalin Marinas wrote:

quoted

On 13 May 2011 20:53, Vadim Bendebury [off-list ref] wrote:

quoted

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

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

On Mon, May 16, 2011 at 7:43 AM, Dave Martin [off-list ref] wrote:

quoted

On Mon, May 16, 2011 at 10:32:16AM -0400, Nicolas Pitre wrote:

quoted

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

On Wed, May 18, 2011 at 06:27:56PM -0400, Nicolas Pitre wrote:

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

quoted

On Mon, May 16, 2011 at 7:43 AM, Dave Martin [off-list ref] wrote:

quoted

On Mon, May 16, 2011 at 10:32:16AM -0400, Nicolas Pitre wrote:

quoted

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 */

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

On Wed, May 18, 2011 at 06:27:56PM -0400, Nicolas Pitre wrote:

quoted

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

quoted

On Mon, May 16, 2011 at 7:43 AM, Dave Martin [off-list ref] wrote:

quoted

On Mon, May 16, 2011 at 10:32:16AM -0400, Nicolas Pitre wrote:

quoted

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

On Wed, May 18, 2011 at 06:49:16PM -0400, Nicolas Pitre wrote:

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

quoted

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.

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

[...]

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