Re: [PATCH v4 10/13] staging: lustre: lnet: lnet: checkpatch.pl fixes

[Drokin, Oleg]

Removal of lustre-added typedefs is worthwhile, actually.
I scraped the surface some time ago, but could not complete it back then.

On May 21, 2015, at 5:47 PM, Michael Shuey wrote:

> I've been killing off a *lot* of checkpatch warnings, and I'm probably getting a tad overzealous.  I'll drop these from the patch series next time I rebase, and avoid doing this in the future.  Thanks for the input.
> 
> Any suggestions on other checkpatch warnings?  Most of what remains are "don't introduce new typedefs" warnings - should these be removed as well, or am I safe to leave these?  I ask because these changes will be huge, and are unlikely to improve readability (but I don't know where the kernel community stands on having billions of typedefs everywhere.
> 
> --
> Mike Shuey
> 
> On Thu, May 21, 2015 at 5:00 PM, Joe Perches <joe@xxxxxxxxxxx> wrote:
> On Thu, 2015-05-21 at 15:50 -0400, Mike Shuey wrote:
> > Fix many checkpatch.pl warnings.
> []
> > diff --git a/drivers/staging/lustre/lnet/lnet/acceptor.c b/drivers/staging/lustre/lnet/lnet/acceptor.c
> []
> > @@ -99,38 +99,42 @@ lnet_connect_console_error(int rc, lnet_nid_t peer_nid,
> >       switch (rc) {
> >       /* "normal" errors */
> >       case -ECONNREFUSED:
> > -             CNETERR("Connection to %s at host %pI4h on port %d was refused: check that Lustre is running on that node.\n",
> > -                     libcfs_nid2str(peer_nid),
> > -                     &peer_ip, peer_port);
> > +             CNETERR(
> > +                     "Connection to %s at host %pI4h on port %d was refused: check that Lustre is running on that node.\n",
> > +                     libcfs_nid2str(peer_nid), &peer_ip, peer_port);
> 
> These are not improvements and checkpatch messages aren't dicta.
> 
> Please don't convert code unless the conversion makes it better
> for a human reader.
> 
> These don't.
> 
> 
> 

--
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/