David Daney wrote:
Ralf Baechle wrote:
On Mon, Oct 13, 2008 at 11:00:30AM -0700, David Daney wrote:
Rewrite cpu_to_name so it has one statement per line.
Future changes can now pass checkpatch.pl
It's been one of those changes where I found the Linux coding style in my
opinion at least, not to be optimal. My plan was to rewrite it like
below
incomplete patch for ages. What do you think?
Ralf
Signed-off-by: Ralf Baechle <ralf@xxxxxxxxxxxxxx>
diff --git a/arch/mips/include/asm/cpu-info.h
b/arch/mips/include/asm/cpu-info.h
index 744cd8f..6d0f891 100644
--- a/arch/mips/include/asm/cpu-info.h
+++ b/arch/mips/include/asm/cpu-info.h
@@ -75,6 +75,7 @@ struct cpuinfo_mips {
unsigned int watch_reg_use_cnt; /* Usable by ptrace */
#define NUM_WATCH_REGS 4
u16 watch_reg_masks[NUM_WATCH_REGS];
+ const char *name;
} __attribute__((aligned(SMP_CACHE_BYTES)));
It increases the size of the cpuinfo_mips structure by sizeof(char *)
for data that is only ever used in /proc/cpuinfo, also it goes against
my sense of data normalization. So I think the current method of
looking it up on demand is fine.
I am not enamored with my patch as it doubles the number of lines in
the function. So we will defer to you and follow which ever style you
decide is best.
David Daney
This is a pretty trivial issue, but I would note that the /proc/cpuinfo code is
not a performance critical path. Thus, adding redundant data isn't worth it. If
we really care about checkpatch and, even in this case, I kinda do, we could
shrink the code by doing a linear scan of a table that contains the CPU type and
the name. If you really care about code and data size *and* want it fast you
could demand that the CPU types be sequentially numbered values, possibly enums,
that you use to index into a table of CPU names.
Okay, I'm done beating this dead horse...
David VomLehn
- - - - - Cisco - - - - -
This e-mail and any attachments may contain information which is confidential,
proprietary, privileged or otherwise protected by law. The information is solely
intended for the named addressee (or a person responsible for delivering it to
the addressee). If you are not the intended recipient of this message, you are
not authorized to read, print, retain, copy or disseminate this message or any
part of it. If you have received this e-mail in error, please notify the sender
immediately by return e-mail and delete it from your computer.
