Re: [PATCH v7 03/19] xfs: Add xfs_has_attr and subroutines

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Feb 23, 2020 at 02:20:32PM +0200, Amir Goldstein wrote:
> On Sun, Feb 23, 2020 at 4:07 AM Allison Collins
> <allison.henderson@xxxxxxxxxx> wrote:
> >
> > From: Allison Henderson <allison.henderson@xxxxxxxxxx>
> >
> > This patch adds a new functions to check for the existence of an attribute.
> > Subroutines are also added to handle the cases of leaf blocks, nodes or shortform.
> > Common code that appears in existing attr add and remove functions have been
> > factored out to help reduce the appearance of duplicated code.  We will need these
> > routines later for delayed attributes since delayed operations cannot return error
> > codes.
> >
> > Signed-off-by: Allison Collins <allison.henderson@xxxxxxxxxx>
> > ---
> >  fs/xfs/libxfs/xfs_attr.c      | 171 ++++++++++++++++++++++++++++--------------
> >  fs/xfs/libxfs/xfs_attr.h      |   1 +
> >  fs/xfs/libxfs/xfs_attr_leaf.c | 111 +++++++++++++++++----------
> >  fs/xfs/libxfs/xfs_attr_leaf.h |   3 +
> >  4 files changed, 188 insertions(+), 98 deletions(-)
> >
> > diff --git a/fs/xfs/libxfs/xfs_attr.c b/fs/xfs/libxfs/xfs_attr.c
> > index 9acdb23..2255060 100644
> > --- a/fs/xfs/libxfs/xfs_attr.c
> > +++ b/fs/xfs/libxfs/xfs_attr.c
> > @@ -46,6 +46,7 @@ STATIC int xfs_attr_shortform_addname(xfs_da_args_t *args);
> >  STATIC int xfs_attr_leaf_get(xfs_da_args_t *args);
> >  STATIC int xfs_attr_leaf_addname(xfs_da_args_t *args);
> >  STATIC int xfs_attr_leaf_removename(xfs_da_args_t *args);
> > +STATIC int xfs_attr_leaf_hasname(struct xfs_da_args *args, struct xfs_buf **bp);
> >
> >  /*
> >   * Internal routines when attribute list is more than one block.
> > @@ -53,6 +54,8 @@ STATIC int xfs_attr_leaf_removename(xfs_da_args_t *args);
> >  STATIC int xfs_attr_node_get(xfs_da_args_t *args);
> >  STATIC int xfs_attr_node_addname(xfs_da_args_t *args);
> >  STATIC int xfs_attr_node_removename(xfs_da_args_t *args);
> > +STATIC int xfs_attr_node_hasname(xfs_da_args_t *args,
> > +                                struct xfs_da_state **state);
> >  STATIC int xfs_attr_fillstate(xfs_da_state_t *state);
> >  STATIC int xfs_attr_refillstate(xfs_da_state_t *state);
> >
> > @@ -310,6 +313,37 @@ xfs_attr_set_args(
> >  }
> >
> >  /*
> > + * Return EEXIST if attr is found, or ENOATTR if not
> 
> This is a very silly return value for a function named has_attr in my taste.
> I realize you inherited this interface from xfs_attr3_leaf_lookup_int(), but
> IMO this change looks like a very good opportunity to change that internal
> API:

tl;dr Cleaning up this API is work for another patchset.

> 
> xfs_has_attr?
> 
> 0: NO
> 1: YES (or stay with the syscall standard of -ENOATTR)
> <0: error

While I agree with your sentiment, Amir, the API you suggest is an
anti-pattern. We've been removing ternary return value APIs like
this from XFS and replacing them with an explicit error return value
and an operational return parameter like so:

	error = xfs_has_attr(&exists)
	if (error)
		return error;

	if (!exists && REPLACE) {
		error = -ENOATTR;
		goto out_error_release;
	}
	if (exists && CREATE) {
		error = -EEXIST;
		goto out_error_release;
	}

	.....

out_error_release:
	xfs_trans_brelse(args->trans, bp);
	return error;

This allows us to separate out fatal metadata fetch and parsing
errors from the operational logic that is run on the status returned
from a successful function call.

IMO, this sort of API change needs to be driven right down into
the internal functions that generate ENOATTR/EEXIST in the first
place. Otherwise all we are doing here is forcing the new code to
translate ENOATTR/EEXIST to some intermediate error code that the
higher layer code then has to convert back to ENOATTR/EEXIST so that
it's callers function properly.

Hence I don't think chagning this API just for this new function
makes the code simpler or easier to maintain. And I don't really
think changing the entire API is in the scope of this work. Hence,
even though I don't like the API, I think it is fine to be retained
for this patchset.

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx



[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux