All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Foster <bfoster@redhat.com>
To: Dave Chinner <david@fromorbit.com>
Cc: xfs@oss.sgi.com
Subject: Re: [DISCUSS] Planning for new dev cycle (3.17)
Date: Thu, 12 Jun 2014 16:01:41 -0400	[thread overview]
Message-ID: <20140612200139.GD3148@laptop.bfoster> (raw)
In-Reply-To: <20140611091020.GO4453@dastard>

On Wed, Jun 11, 2014 at 07:10:20PM +1000, Dave Chinner wrote:
> On Wed, Jun 11, 2014 at 07:48:50AM +1000, Dave Chinner wrote:
> > On Tue, Jun 10, 2014 at 07:58:57AM -0400, Brian Foster wrote:
> > > On Tue, Jun 10, 2014 at 08:33:20AM +1000, Dave Chinner wrote:
> > > > The issue is the negative error number patchset, and how to handle
> > > > review and testing. The patchset is already 62 patches long and it
> > > > converts roughly half the code base. It'll take me another couple of
> > > > days to convert the rest of the code, and that will probably take
> > > > another 60 patches.
> > > > 
> > > > I understand that reviewing 100+ patches is going to be a pain, but
> > > > each patch currently averages about +/- 10 lines. The current
> > > > diffstat is:
> > > > 
> > > > 	37 files changed, 723 insertions(+), 722 deletions(-)
> > > > 
> > > > And that will probably double, so it's still going to be a fair
> > > > amount of change.
> > > 
> > > Is there any sort of more coarse logical breakdown of this series, or do
> > > we want/need to convert the entire codebase all at once? The individual
> > > patches sound relatively small... is there a particular method at play
> > > there? E.g., a patch per function? file? call chain?
> > 
> > I'm doing it layer by layer, starting from the linux interface
> > layers and working my way down. e.g. fs/xfs/xfs_file.c first,
> > the fs/xfs/xfs_iops.c, and so on, and there are multiple patches per
> > file for each (roughly) logical change. e.g. converting xfs_iops.c:
> [...]
> 
> I've decided that there really is too much unnecessary code churn
> from this approach. I end up converting all the call sites to negate
> the error sign, and then end up converting them back to the original
> code some time later, leaving only the source of the errors with a
> changed sign.
> 
> So, I stopped doing that to see just what the brute force, change
> source and conversions only, and I found with a few simple searches
> I could identify all the locations that need changing. So, in a
> couple of hours I churned out the patch that converted everything.
> Still pretty large, even though it only changes error values and
> conversion points.
> 
> 67 files changed, 879 insertions(+), 884 deletions(-)
> 
> Not sure how I could break this up - it really is an all-or-nothing
> patch this Big Hammer approach....
> 

Yeah, now that I look at it, it's kind of hard to review as any other
way as well. I've done some grepping and made a pass through all of the
changes. I noticed some very minor things like not all of the comments
being converted and some multi-line parameter lists going out of
alignment, but I didn't bother to even make notes of those.

I've gone through an xfstests run without any explosions as well.

A couple general observations:

- I assume the xfs_buf->b_error type change is intentional..?
- Same for the change in value for the ASSERT(error <=0 && error >=
  -1000) assert in xfs_buf_ioerror (previously it used 64k).

... and I saw a few spots that looked like could still need conversion.
A diff is inlined below.

Brian

---8<---

diff --git a/fs/xfs/xfs_attr_list.c b/fs/xfs/xfs_attr_list.c
index e76f687..62db83a 100644
--- a/fs/xfs/xfs_attr_list.c
+++ b/fs/xfs/xfs_attr_list.c
@@ -648,6 +648,6 @@ xfs_attr_list(
 	alist->al_offset[0] = context.bufsize;
 
 	error = xfs_attr_list_int(&context);
-	ASSERT(error >= 0);
+	ASSERT(error <= 0);
 	return error;
 }
diff --git a/fs/xfs/xfs_ioctl32.c b/fs/xfs/xfs_ioctl32.c
index 7207e9d..e65ea67 100644
--- a/fs/xfs/xfs_ioctl32.c
+++ b/fs/xfs/xfs_ioctl32.c
@@ -376,7 +376,7 @@ xfs_compat_attrlist_by_handle(
 		goto out_dput;
 
 	cursor = (attrlist_cursor_kern_t *)&al_hreq.pos;
-	error = -xfs_attr_list(XFS_I(dentry->d_inode), kbuf, al_hreq.buflen,
+	error = xfs_attr_list(XFS_I(dentry->d_inode), kbuf, al_hreq.buflen,
 					al_hreq.flags, cursor);
 	if (error)
 		goto out_kfree;
@@ -515,7 +515,7 @@ xfs_compat_fssetdm_by_handle(
 		goto out;
 	}
 
-	error = -xfs_set_dmattrs(XFS_I(dentry->d_inode), fsd.fsd_dmevmask,
+	error = xfs_set_dmattrs(XFS_I(dentry->d_inode), fsd.fsd_dmevmask,
 				 fsd.fsd_dmstate);
 
 out:

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

  reply	other threads:[~2014-06-12 20:02 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-09 22:33 [DISCUSS] Planning for new dev cycle (3.17) Dave Chinner
2014-06-10  6:09 ` Dave Chinner
2014-06-10 14:09   ` Eric Sandeen
2014-06-10 21:54     ` Dave Chinner
2014-06-10 21:57     ` Eric Sandeen
2014-06-10 11:58 ` Brian Foster
2014-06-10 21:48   ` Dave Chinner
2014-06-11  9:10     ` Dave Chinner
2014-06-12 20:01       ` Brian Foster [this message]
2014-06-12 23:28         ` Dave Chinner

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=20140612200139.GD3148@laptop.bfoster \
    --to=bfoster@redhat.com \
    --cc=david@fromorbit.com \
    --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.