lkml.org 
[lkml]   [2008]   [Apr]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [v2.6.26] what's brewing in x86.git for v2.6.26
On Thu, 17 Apr 2008 22:39:55 +0200
"Vegard Nossum" <vegard.nossum@gmail.com> wrote:

> Hi Andrew,
>
> Thank you very much for the review of this patch. Those are hard to
> come by, and I've posted kmemcheck to LKML already 3 or 4 times, with
> relatively sparse response. I mean, the fact that they were ALL
> whitespace damaged, but discovered by nobody, quite plainly tells me
> that nobody actually tried to apply it (except perhaps Daniel Walker,
> but we never realized it was whitespace damage causing the problems).
> The patches that Ingo took into x86 were probably sent as an
> attachment...

hm. Our review problem is well-understood.

> to Ingo before sending this to the list, so he should know. But it
> should not have been part of this patch, I agree.
>
> > > early_param("kmemcheck", param_kmemcheck);
> >
> > kmemcheck= is documented in at least three places, which is nice, but it
> > isn't mentioned in the place where we document kernel-parameters:
> > Documentation/kernel-parameters.txt. A brief section there which directs
> > the user to the extended docs would be fine.
> >
> > early_param() is unusual - we normally use __setup(). I assume there's a
> > reason for using early_param(), but that reason cannot be discerned from
> > reading the code. A /*comment*/ is the way to fix that.
>
> The reason is that we need to set this before kmalloc() is ever
> called. A comment will come.
>
> But it seems that __setup() is what is really missing a comment. I
> don't know what it is or how it works, and the comments around the
> definition are not very helpful. Maybe somebody could enlighten me?

It makes my head spin too. Reading through the first bit of
init/main.c:start_kernel() is your best hope, sorry.

> > > +static pte_t *
> > > +address_get_pte(unsigned int address)
> >
> > This is not the preferred way of laying out function declarations but I've
> > basically given up on this one.
> >
> > (void *)address
> >
> > is more common, but I'm close to giving up on that too.
> >
> > > static int
> > > -show_addr(uint32_t addr)
> > > +show_addr(uint32_t address)
> >
> > u32 is preferred, but ditto.
>
> This will be turned into unsigned long with 64-bit support. (Hopefully
> we can get that working too.)
>
> Changing these to match the rest of the kernel is no problem for me.
> It is not the way I would write it, but Pekka and Ingo has already
> forced me to write if () instead of if(), so there should be no reason
> to stop here! :-)

These things are OK as-is, I think. It'd be somewhat less nice in
situations where newly-added code was inconsistent with surrounding
existing code but it's still hardly a huge problem.

> > Perhaps we should get all this code onto the list(s) for re-review. It's
> > been a while..
>
> I'm not sure it would make much of a difference, except perhaps for
> you, if you want to review it all. (My latest post to LKML had 0
> replies in total. Well, except private e-mail exchange with Ingo and
> Pekka; they should know the code already. Once again, thanks to them
> for helping me.) Do you still want me to post it again?

mm... I wouldn't mind taking a closer look at it all. That documentation
file makes it _much_ easier to review the code, and the review becomes more
effective than it would otherwise be.

>
> PS: And it's not that I do that much testing/reviewing myself. But I
> do think I have the excuse of being a newbie at this :-)

You're in good company ;)


\
 
 \ /
  Last update: 2008-04-17 22:59    [W:0.081 / U:0.388 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site