Re: [PATCH 06/20] mem_class: use minor as index instead ofsearching the array

From: Greg KH
Date: Tue Sep 15 2009 - 16:27:46 EST


On Tue, Sep 15, 2009 at 01:07:09PM -0700, Daniel Walker wrote:
> On Tue, 2009-09-15 at 21:46 +0200, Kay Sievers wrote:
> > On Tue, Sep 15, 2009 at 21:42, Daniel Walker <dwalker@xxxxxxxxxx> wrote:
> > > On Tue, 2009-09-15 at 12:12 -0700, Greg Kroah-Hartman wrote:
> > >> +static const struct memdev {
> > >> + const char *name;
> > >> + const struct file_operations *fops;
> > >> + struct backing_dev_info *dev_info;
> > >> +} devlist[] = {
> > >> + [ 1] = { "mem", &mem_fops, &directly_mappable_cdev_bdi },
> > >
> > > This patch has several checkpatch errors wrt. the spacing used in the
> > > array index..
> > >
> > > Kay, can you send a follow up patch to correct them?
> >
> > I think they are fine, and properly aligned to be best readable.
>
> We already have a coding style in Linux which doesn't allow this type of
> alignment .. If we allowed everyone to pick their own coding style we
> would have a pretty ugly looking kernel.. That's why the checkpatch tool
> was create to test for style conformance.. If you feel strongly about
> this alignment you could change checkpatch not to warn on this , but I
> don't think it's likely a change like that would be accepted..

I explicitly ignored the checkpatch warnings here, as Kay is right, it
does look better and is more sane with the way he wrote it.

Remember, checkpatch.pl is a _guide_ not a
hard-and-fast-rule-or-else-puppies-will-get-hurt type of a thing.

The whole reason for having a consistant coding style is so your brain
gets used to patterns and you can see the context of the code instead.
It's a proven thing. Arguing that removing that space makes it easier
to understand and maintain over time is illogical.

thanks,

greg k-h
--
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/