[Top] [All Lists]

Re: [PATCH 08/16] xfs: change interface of xfs_nameops.hashname

To: Ben Myers <bpm@xxxxxxx>
Subject: Re: [PATCH 08/16] xfs: change interface of xfs_nameops.hashname
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Tue, 7 Oct 2014 09:17:08 +1100
Cc: linux-fsdevel@xxxxxxxxxxxxxxx, olaf@xxxxxxx, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20141003215844.GG1865@xxxxxxx>
References: <20141003214758.GY1865@xxxxxxx> <20141003215844.GG1865@xxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Fri, Oct 03, 2014 at 04:58:44PM -0500, Ben Myers wrote:
> From: Olaf Weber <olaf@xxxxxxx>
> With the introduction of the xfs_nameops.normhash callout, all uses of the
> hashname callout now occur in places where an xfs_name structure must be
> explicitly created just to match the parameter passing convention of this
> callout. Change the arguments to a const unsigned char * and int instead.
> Signed-off-by: Olaf Weber <olaf@xxxxxxx>
> [v2: pass a 3rd argument for sb_utf8version to hashname.  --bpm]

So now I've looked at most of the rest of the patch set, I think
this is the wrong thing to do. I see no reason apart from "it's less
typing" to drop the use of the xfs-name structure, but it removes a
key piece of documentation from the code. i.e. that the name/namelen
are an inseparable tuple and cannot be separated. Indeed, lots of
the utf8 xfs code declares norm/normlen tuples on the stack for
temporary use, so really this comes down to a matter of taste.

And in that matter, I'd prefer that we keep the existing name
abstaction and propagate it into the new code rather than the other
way around.


Dave Chinner

<Prev in Thread] Current Thread [Next in Thread>