| Message ID | 83d98772-8872-1b75-a9a5-5f08b8462e18@users.sourceforge.net (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 16/10/16 21:03, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sun, 16 Oct 2016 20:48:28 +0200 > > Some data were printed into a sequence by six separate function calls. > Print the same data by a single function call instead. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> > arch/arm64/kernel/cpuinfo.c | 19 +++++++++++-------- > 1 file changed, 11 insertions(+), 8 deletions(-) > > diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c > index b3d5b3e..f22687d 100644 > --- a/arch/arm64/kernel/cpuinfo.c > +++ b/arch/arm64/kernel/cpuinfo.c > @@ -148,14 +148,17 @@ static int c_show(struct seq_file *m, void *v) > if (elf_hwcap & (1 << j)) > seq_printf(m, " %s", hwcap_str[j]); > } > - seq_puts(m, "\n"); > - > - seq_printf(m, "CPU implementer\t: 0x%02x\n", > - MIDR_IMPLEMENTOR(midr)); > - seq_printf(m, "CPU architecture: 8\n"); > - seq_printf(m, "CPU variant\t: 0x%x\n", MIDR_VARIANT(midr)); > - seq_printf(m, "CPU part\t: 0x%03x\n", MIDR_PARTNUM(midr)); > - seq_printf(m, "CPU revision\t: %d\n\n", MIDR_REVISION(midr)); > + seq_printf(m, > + "\n" > + "CPU implementer\t: 0x%02x\n" > + "CPU architecture: 8\n" > + "CPU variant\t: 0x%x\n" > + "CPU part\t: 0x%03x\n" > + "CPU revision\t: %d\n\n", > + MIDR_IMPLEMENTOR(midr), > + MIDR_VARIANT(midr), > + MIDR_PARTNUM(midr), > + MIDR_REVISION(midr)); > } > > return 0; >
On Sun, Oct 16, 2016 at 09:03:52PM +0200, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sun, 16 Oct 2016 20:48:28 +0200 > > Some data were printed into a sequence by six separate function calls. > Print the same data by a single function call instead. ... why? Beyond simply having fewer function calls, is there an upside? This makes it harder to see the relationship between the format strings and their associated data, and makes the code longer. Thanks, Mark. > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > arch/arm64/kernel/cpuinfo.c | 19 +++++++++++-------- > 1 file changed, 11 insertions(+), 8 deletions(-) > > diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c > index b3d5b3e..f22687d 100644 > --- a/arch/arm64/kernel/cpuinfo.c > +++ b/arch/arm64/kernel/cpuinfo.c > @@ -148,14 +148,17 @@ static int c_show(struct seq_file *m, void *v) > if (elf_hwcap & (1 << j)) > seq_printf(m, " %s", hwcap_str[j]); > } > - seq_puts(m, "\n"); > - > - seq_printf(m, "CPU implementer\t: 0x%02x\n", > - MIDR_IMPLEMENTOR(midr)); > - seq_printf(m, "CPU architecture: 8\n"); > - seq_printf(m, "CPU variant\t: 0x%x\n", MIDR_VARIANT(midr)); > - seq_printf(m, "CPU part\t: 0x%03x\n", MIDR_PARTNUM(midr)); > - seq_printf(m, "CPU revision\t: %d\n\n", MIDR_REVISION(midr)); > + seq_printf(m, > + "\n" > + "CPU implementer\t: 0x%02x\n" > + "CPU architecture: 8\n" > + "CPU variant\t: 0x%x\n" > + "CPU part\t: 0x%03x\n" > + "CPU revision\t: %d\n\n", > + MIDR_IMPLEMENTOR(midr), > + MIDR_VARIANT(midr), > + MIDR_PARTNUM(midr), > + MIDR_REVISION(midr)); > } > > return 0; > -- > 2.10.1 > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >
>> Some data were printed into a sequence by six separate function calls. >> Print the same data by a single function call instead. > > ... why? > > Beyond simply having fewer function calls, is there an upside? Will it matter to improve run time characteristics at this source code place? > This makes it harder to see the relationship between the format strings > and their associated data, and makes the code longer. Do you prefer an other layout for the passed data so that the increase of line count in my update suggestion would look differently? Regards, Markus
On Mon, Oct 17, 2016 at 01:30:59PM +0200, SF Markus Elfring wrote: > >> Some data were printed into a sequence by six separate function calls. > >> Print the same data by a single function call instead. > > > > ... why? > > > > Beyond simply having fewer function calls, is there an upside? > > Will it matter to improve run time characteristics at this source code > place? I do not know. If that's not the aim of your existing patch, then I have no idea what you're trying to achieve. > > This makes it harder to see the relationship between the format strings > > and their associated data, and makes the code longer. > > Do you prefer an other layout for the passed data so that the increase > of line count in my update suggestion would look differently? I prefer the code as-is. Unless there's a compelling reason to change it. Thanks, Mark.
> I prefer the code as-is. Unless there's a compelling reason to change it.
Is the chance for faster log output interesting enough?
Regards,
Markus
On Mon, Oct 17, 2016 at 02:50:57PM +0200, SF Markus Elfring wrote: > > I prefer the code as-is. Unless there's a compelling reason to change it. > > Is the chance for faster log output interesting enough? Is there a particular user that cares today, or are we trying to work backwards to a rationale? Thanks, Mark.
diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c index b3d5b3e..f22687d 100644 --- a/arch/arm64/kernel/cpuinfo.c +++ b/arch/arm64/kernel/cpuinfo.c @@ -148,14 +148,17 @@ static int c_show(struct seq_file *m, void *v) if (elf_hwcap & (1 << j)) seq_printf(m, " %s", hwcap_str[j]); } - seq_puts(m, "\n"); - - seq_printf(m, "CPU implementer\t: 0x%02x\n", - MIDR_IMPLEMENTOR(midr)); - seq_printf(m, "CPU architecture: 8\n"); - seq_printf(m, "CPU variant\t: 0x%x\n", MIDR_VARIANT(midr)); - seq_printf(m, "CPU part\t: 0x%03x\n", MIDR_PARTNUM(midr)); - seq_printf(m, "CPU revision\t: %d\n\n", MIDR_REVISION(midr)); + seq_printf(m, + "\n" + "CPU implementer\t: 0x%02x\n" + "CPU architecture: 8\n" + "CPU variant\t: 0x%x\n" + "CPU part\t: 0x%03x\n" + "CPU revision\t: %d\n\n", + MIDR_IMPLEMENTOR(midr), + MIDR_VARIANT(midr), + MIDR_PARTNUM(midr), + MIDR_REVISION(midr)); } return 0;