Re: [PATCH x86] [5/16] Replace hard coded reservations in x86-64early boot code with dynamic table II

From: Ingo Molnar
Date: Fri Jan 04 2008 - 09:42:15 EST



* Andi Kleen <ak@xxxxxxx> wrote:

> On Friday 04 January 2008 10:00:52 Ingo Molnar wrote:
> >
> > * Andi Kleen <ak@xxxxxxx> wrote:
> >
> > > On x86-64 there are several memory allocations before bootmem. To
> > > avoid them stomping on each other they used to be all hard coded in
> > > bad_area(). Replace this with an array that is filled as needed.
> > >
> > > This cleans up the code considerably and allows to expand its use.
> >
> > this code introduces a number of style errors that make the code harder
> > to read and follow. Please fix them.
>
> I reviewed the code now and I honestly don't see any "style errors" so
> I don't know how to change it.
>
> -Andi

there are 7 style problems in the patch. Checkpatch.pl gives two:

ERROR: use tabs not spaces
#92: FILE: arch/x86/kernel/e820_64.c:89:
+ ^I}$

ERROR: use tabs not spaces
#135: FILE: arch/x86/kernel/e820_64.c:107:
+ ^I}$

total: 2 errors, 0 warnings, 308 lines checked

i'm not sure how you manage patches - if you have some 'refresh patch'
command then you might want to stick a call to scripts/checkpatch.pl in
there. I have such a check included in my quilt refresh shortcut.

#3:

+ int i;
+ struct early_res *r;
+ for (i = 0; i < MAX_EARLY_RES && early_res[i].end; i++) {
+ r = &early_res[i];

newline needed after the variables.

#4:

void __init early_res_to_bootmem(void)
{
int i;
for (i = 0; i < MAX_EARLY_RES && early_res[i].end; i++) {
struct early_res *r = &early_res[i];
reserve_bootmem_generic(r->start, r->end - r->start);

the variables definition here is totally misaligned.

#5:

+ int changed = 0;
+again:
+ last = addr + size;

newline needed before the 'again:'.

#6:

+ struct early_res *r = &early_res[i];
+ if (last >= r->start && addr < r->end) {

newline needed after the variables.

#7:

+ unsigned long ramdisk_end = ramdisk_image + ramdisk_size;
+ reserve_early(ramdisk_image, ramdisk_end);

newline needed after the variables.

from your other mail:

> [...] Also I didn't realize that white space was more important than
> seriously cleaner code now.

here's my opinion about this topic:

- style cleanliness is an admittedly secondary concept but it
strengthens the most important, primary aspect of any code:
readability and maintainability.

- sloppy style is also often a statistical indicator for sloppy quality:
code written in rush, not reviewed and not read well enough. I'm not
implying anything like that about this patch of yours, but it's a
general policy and you'd sure agree that writing 100% clean code is
not that much harder than just writing good code.

- cleanup is generally pushed back to patch submitters - this
distributes better as it removes load from maintainers (and subsequent
patch developers).

- it's also a matter of visual taste. People are more likely to fix and
improve clean _looking_ code than messy looking code. It's often the
first stepping stone towards reaching structural cleanliness. And
frankly, rarely have i seen any genuinely clean code that had a messy
style - messy visual output is usually the mirror image of lack of
interest or lack of time. (i'd be glad if anyone could point me
towards any genuinely clean code within the kernel that nevertheless
has messy style.)

So please dont take this personal in any way - you'll see many other
checkpatch.pl related patch rejections on lkml, from me and from others
as well. Sloppy style does mount up step by step and results in harder
to read and harder to fix/maintain code.

White space is not at all more important than seriously cleaner code,
but 'even more seriously clean code' is more important than just pure
seriously clean code ;-)

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