All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Bill O'Donnell" <billodo@redhat.com>
To: Dave Chinner <david@fromorbit.com>
Cc: Eric Sandeen <sandeen@sandeen.net>, xfs@oss.sgi.com
Subject: Re: [PATCH 5/5] xfs: incorporate sysfs/kobject in xfsstats: handlers take kobjects.
Date: Thu, 24 Sep 2015 16:26:58 -0500	[thread overview]
Message-ID: <20150924212658.GA21293@redhat.com> (raw)
In-Reply-To: <20150922222636.GM19114@dastard>

On Wed, Sep 23, 2015 at 08:26:36AM +1000, Dave Chinner wrote:
> On Tue, Sep 22, 2015 at 10:16:05AM -0500, Bill O'Donnell wrote:
> > > >  		goto out;
> > > >  
> > > >  	if (!proc_symlink("fs/xfs/stat", NULL,
> > > > -			  "/sys/fs/xfs/stats/stats"))
> > > > +			"/sys/fs/xfs/stats/stats"))
> > > 
> > > intentional whitespace changes?
> > > 
> > > >  		goto out_remove_xfs_dir;
> > > >  
> > > >  #ifdef CONFIG_XFS_QUOTA
> > > >  	if (!proc_create("fs/xfs/xqmstat", 0, NULL,
> > > > -			 &xqmstat_proc_fops))
> > > > +			&xqmstat_proc_fops))
> > > >  		goto out_remove_stat_file;
> > > >  	if (!proc_create("fs/xfs/xqm", 0, NULL,
> > > > -			 &xqm_proc_fops))
> > > > +			&xqm_proc_fops))
> > > 
> > > Same question.  (did checkpatch complain or something?)
> > 
> > Yes. Checkpatch didn't like any spaces, so I turned em into tabs.
> 
> Checkpatch should be considered harmful.
> 
> It's a good starting point, but it ends up doing more harm than good
> because it doesn't understand the subtle differences in code across
> different subsystems.
> 
> In this case, the standard we use for XFS is that multi-line
> parameters should be lined up with the first parameter, unless the
> new parameters don't fit on a single line, and then we back up the
> indent by a tab at a time. i.e. This is correct:
> 
> 	if (!proc_create("fs/xfs/xqm", 0, NULL,
> 			 &xqm_proc_fops))
> 
> regardless of what checkpatch says. Indeed, if checkpatch had any
> brains, it would have noticed that a line break is not necessary
> as this:
> 
> 	if (!proc_create("fs/xfs/xqm", 0, NULL, &xqm_proc_fops))
> 
> fits in 80 columns just fine.
> 
> Remember that Documentation/CodingStyle is a set of guidelines, not
> a strict, enforcable set of rules.  The basic guidelines canbe
> summarised as:
> 
> 	1. Use the same style as the existing code in the file,
> 	   unless reviewers/maintainers ask otherwise.
> 	2. new files should follow the format used in other files in
> 	   the subsystem, unless reviewers/maintainer asks otherwise.
> 	3. Do not reformat code that you don't need to directly
> 	   modify in the patch.
> 	4. modify your editor to highlight common style things that
> 	   you need reminders to get right
> 	5. Immolate checkpatch before the plague spreads further
> 
> As to #4, there's plenty of simple things you can do. e.g to
> identify stray whitespace in files, add this to your .vimrc file
> (you can do similar with emacs, google it):
> 
> 	" highlight whitespace damage
> 	highlight RedundantSpaces ctermbg=red guibg=red
> 	match RedundantSpaces /\s\+$\| \+\ze\t/
> 
> This will catch things like "tab-space-tab" and it will also find
> trailing whitespace at the end of lines. They will appear in red.
> 
> > > > -#define XFS_STATS_INC(v)	(per_cpu(xfsstats, current_cpu()).v++)
> > > > -#define XFS_STATS_DEC(v)	(per_cpu(xfsstats, current_cpu()).v--)
> > > > -#define XFS_STATS_ADD(v, inc)	(per_cpu(xfsstats, current_cpu()).v += (inc))
> > > > +#define XFS_STATS_INC(v)	(per_cpu(*xfsstats.xs_stats, current_cpu()).v++)
> > > > +#define XFS_STATS_DEC(v)	(per_cpu(*xfsstats.xs_stats, current_cpu()).v--)
> > > > +#define XFS_STATS_ADD(v, inc)	(per_cpu(*xfsstats.xs_stats, current_cpu()).v += (inc))
> > > 
> > > Line > 80 chars
> > 
> > I'll fix it.
> 
> Checkpatch got changed not to warn about that, because too many
> people complained about it when modifying files with >80 column
> formatting.
> 
> To that end, I also use custom column width highlights based on file
> names so that line wrapping occurs automatically at the correct
> spot, and when looking at code I can clearly see long lines:
> 
> 	" set the textwidth to 80 characters by default
> 	set tw=80
> 
> 	" set the textwidth to 68 characters for guilt commit messages
> 	au BufNewFile,BufRead guilt.msg.*,.gitsendemail*,.git* set tw=68
> 
> 	" set the textwidth to 68 characters for replies (email&usenet)
> 	au BufNewFile,BufRead .letter,mutt*,nn.*,snd.* set tw=68
> 
> 	" highlight textwidth
> 	set cc=+1
> 
> If you do little things like this, the need for checkpatch goes
> away. With a default tw=80 and a highlight, I only have to glance
> at a patch to know it has lines longer than 80 columns in it.
> 
> As such, I haven't used checkpatch for years, and I recommend that
> you develop the right habits and automation such that you don't need
> to use it after a couple of months, either...

All points well taken. I'm fixing it all up in the next patch!

Thanks!
Bill

> 
> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

      reply	other threads:[~2015-09-24 21:27 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-22 12:07 [PATCH 0/5 v7] xfs: stats in sysfs Bill O'Donnell
2015-09-22 12:07 ` [PATCH 1/5] xfs: create global stats and stats_clear " Bill O'Donnell
2015-09-22 12:07 ` [PATCH 2/5] xfs: create symlink proc/fs/xfs/stat to sys/fs/xfs/stats Bill O'Donnell
2015-09-22 12:07 ` [PATCH 3/5] xfs: remove unused procfs code Bill O'Donnell
2015-09-22 12:07 ` [PATCH 4/5] xfs: consolidate sysfs ops (dbg, stats, log) Bill O'Donnell
2015-09-22 12:07 ` [PATCH 5/5] xfs: incorporate sysfs/kobject in xfsstats: handlers take kobjects Bill O'Donnell
2015-09-22 14:47   ` Eric Sandeen
2015-09-22 15:16     ` Bill O'Donnell
2015-09-22 22:26       ` Dave Chinner
2015-09-24 21:26         ` Bill O'Donnell [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150924212658.GA21293@redhat.com \
    --to=billodo@redhat.com \
    --cc=david@fromorbit.com \
    --cc=sandeen@sandeen.net \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.