From: Ingo Molnar on

* Joe Perches <joe(a)perches.com> wrote:

> Needed if pr_<level> becomes a bit more space efficient.
>
> Signed-off-by: Joe Perches <joe(a)perches.com>
> ---
> arch/x86/kernel/cpu/mtrr/cleanup.c | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/kernel/cpu/mtrr/cleanup.c b/arch/x86/kernel/cpu/mtrr/cleanup.c
> index 06130b5..c5f59d0 100644
> --- a/arch/x86/kernel/cpu/mtrr/cleanup.c
> +++ b/arch/x86/kernel/cpu/mtrr/cleanup.c
> @@ -632,9 +632,9 @@ static void __init mtrr_print_out_one_result(int i)
> unsigned long gran_base, chunk_base, lose_base;
> char gran_factor, chunk_factor, lose_factor;
>
> - gran_base = to_size_factor(result[i].gran_sizek, &gran_factor),
> - chunk_base = to_size_factor(result[i].chunk_sizek, &chunk_factor),
> - lose_base = to_size_factor(result[i].lose_cover_sizek, &lose_factor),
> + gran_base = to_size_factor(result[i].gran_sizek, &gran_factor);
> + chunk_base = to_size_factor(result[i].chunk_sizek, &chunk_factor);
> + lose_base = to_size_factor(result[i].lose_cover_sizek, &lose_factor);

That file and this subsystem needs a lot more cleanups than just this. Would
you be willing to do them all, so that we can get over with the churn in a
single well-defined patch (or patches)?

I dont see much point in piecemail single-comma patches - i'd rather wait for
someone else who'd fix this and other details in one go.

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Joe Perches on
On Tue, 2010-06-29 at 02:14 +0200, Ingo Molnar wrote:
> That file and this subsystem needs a lot more cleanups than just this. Would
> you be willing to do them all, so that we can get over with the churn in a
> single well-defined patch (or patches)?
>
> I dont see much point in piecemail single-comma patches - i'd rather wait for
> someone else who'd fix this and other details in one go.

I don't see significant style issues in mtrr

$ git ls-files arch/x86/kernel/cpu/mtrr/ | \
xargs ./scripts/checkpatch.pl -f

What do you think needs improving?git ls-files arch/x86/kernel/cpu/mtrr/
| \
xargs ./scripts/checkpatch.pl -f

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Joe Perches on
On Tue, 2010-06-29 at 02:14 +0200, Ingo Molnar wrote:
> * Joe Perches <joe(a)perches.com> wrote:
>
> > Needed if pr_<level> becomes a bit more space efficient.
> >
> > Signed-off-by: Joe Perches <joe(a)perches.com>
> > ---
> > arch/x86/kernel/cpu/mtrr/cleanup.c | 6 +++---
> > 1 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/x86/kernel/cpu/mtrr/cleanup.c b/arch/x86/kernel/cpu/mtrr/cleanup.c
> > index 06130b5..c5f59d0 100644
> > --- a/arch/x86/kernel/cpu/mtrr/cleanup.c
> > +++ b/arch/x86/kernel/cpu/mtrr/cleanup.c
> > @@ -632,9 +632,9 @@ static void __init mtrr_print_out_one_result(int i)
> > unsigned long gran_base, chunk_base, lose_base;
> > char gran_factor, chunk_factor, lose_factor;
> >
> > - gran_base = to_size_factor(result[i].gran_sizek, &gran_factor),
> > - chunk_base = to_size_factor(result[i].chunk_sizek, &chunk_factor),
> > - lose_base = to_size_factor(result[i].lose_cover_sizek, &lose_factor),
> > + gran_base = to_size_factor(result[i].gran_sizek, &gran_factor);
> > + chunk_base = to_size_factor(result[i].chunk_sizek, &chunk_factor);
> > + lose_base = to_size_factor(result[i].lose_cover_sizek, &lose_factor);
>
> That file and this subsystem needs a lot more cleanups than just this. Would
> you be willing to do them all, so that we can get over with the churn in a
> single well-defined patch (or patches)?
>
> I dont see much point in piecemail single-comma patches - i'd rather wait for
> someone else who'd fix this and other details in one go.

This is the only "," preceeding a pr_<level> printk
in the kernel tree.

The comma prevents the pr_<level> macro to take the
"do { foo } while (0)" form.

I don't see significant issues in the code style that
need cleanups in arch/x86/kernel/cpu/mtrr.

What do you think needs cleaning?


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Thomas Gleixner on
On Wed, 14 Jul 2010, Joe Perches wrote:

Sorry, but that's one of the most convoluted changelogs I ever saw.

> These are the only "," terminated statements that
> precede a pr_<level> in the kernel tree.

Errm, why is this related to pr_<level> in any way ?

> These must be ";" terminated if the pr_<level>
> macros becomes a bit more space efficient using
> a "do { foo } while (0)" form.

It has absolutely _NOTHING_ to do with any implementation detail of
the function/macro which comes after those statements.

Terminating a statement with a comma is simply wrong by itself and it
needs to be fixed w/o further ado.

Thanks,

tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Joe Perches on
On Thu, 2010-07-15 at 00:00 +0200, Thomas Gleixner wrote:
> On Wed, 14 Jul 2010, Joe Perches wrote:
> that's one of the most convoluted changelogs I ever saw.
> > These are the only "," terminated statements that
> > precede a pr_<level> in the kernel tree.
> Terminating a statement with a comma is simply wrong by itself and it
> needs to be fixed w/o further ado.

Great. So remove the changelog and just use the subject.

I sent a simpler changelog patch last month.
http://lkml.org/lkml/2010/6/28/349

Ingo rejected it.

He said there were other style problems in the file that
needed cleaning. I asked what those style problems were.
checkpatch and his "code-quality" script don't show
significant issues. No reply from Ingo.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/