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 Tue, Feb 25, 2020 at 08:43:53AM +0200, Amir Goldstein wrote:
> On Tue, Feb 25, 2020 at 8:26 AM Dave Chinner <david@xxxxxxxxxxxxx> wrote:
> >
> > 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;
> >
> 
> That would be neat and tidy.
> 
> One of the outcomes of new reviewers is comments on code unrelated
> to the changes... I have no problem of keeping API as is for Allison's
> change, but I did want to point out that the API became worse to read
> due to the helper name change from _lookup_attr to _has_attr, which
> really asks for a yes or no answer.

No argument from me on that. :P

But we really need to make progress on the new attribute features
rather than get bogged down in completely rewriting the attribute
code because it's a bit gross and smelly. The smell can be removed
later...

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