From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail104.syd.optusnet.com.au ([211.29.132.246]:40014 "EHLO mail104.syd.optusnet.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725804AbfDOVSy (ORCPT ); Mon, 15 Apr 2019 17:18:54 -0400 Date: Tue, 16 Apr 2019 07:18:51 +1000 From: Dave Chinner Subject: Re: [PATCH 1/9] xfs: Remove all strlen in all xfs_attr_* functions for attr names. Message-ID: <20190415211851.GF29573@dread.disaster.area> References: <20190412225036.22939-1-allison.henderson@oracle.com> <20190412225036.22939-2-allison.henderson@oracle.com> <20190414230259.GE29573@dread.disaster.area> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-xfs-owner@vger.kernel.org List-ID: List-Id: xfs To: Allison Henderson Cc: linux-xfs@vger.kernel.org On Mon, Apr 15, 2019 at 01:08:50PM -0700, Allison Henderson wrote: > On 4/14/19 4:02 PM, Dave Chinner wrote: > > On Fri, Apr 12, 2019 at 03:50:28PM -0700, Allison Henderson wrote: > > > This helps to pre-simplify the extra handling of the null terminator in > > > delayed operations which use memcpy rather than strlen. Later > > > when we introduce parent pointers, attribute names will become binary, > > > so strlen will not work at all. Removing uses of strlen now will > > > help reduce complexities later > > > > > > Signed-off-by: Allison Henderson > > > Reviewed-by: Darrick J. Wong > > > > Hmmm. If we are going to pass name/namelen pairs around everywhere, > > can we convert these to a struct xfs_name? > > > > I also wonder where we should convert the name/namelen pairs in the > > attr args struct to an xfs_name, too, then we can just do: > > > > args->name = *name; > > > > to copy in the string pointer and the name length in one go. > > > > And we might even be able to put the attribute flags (e.g. > > ATTR_ROOT) in the name.type field, and get rid of that parameter > > being passed around, too... > > > > Cheers, > > > > Dave. > > I think a new struct xfs_name is reasonable. Or maybe a general purpose > xfs_array? The value/valuelen parameters have a similar relation that could > make use of that too. How would people feel about something like this: > > struct xfs_array { > unsigned char *bytes; > size_t len; > } > > struct xfs_attribute { > struct xfs_array name; > int flags; > } Hmmm. I think that's overkill - we really don't need that much abstraction and it makes the code more complex rather than simplifies it. i.e. args->name.name.bytes isn't really a simplification... Also the above means we have to discard the const part of the names we are passed because this construction doesn't appear to be intended for read only strings. i.e.: > We could add the value member in here too. Which is something that isn't const. :) > It tends to get passed around > just as much with the exception of attr remove operations which only need > the name. I think changing the actual members of xfs_da_args should be > another patch though, since that's a bigger change that affects a wider > scope of code. I can look into it though. I don't think we want anything more complex or to extent it to include other parts of the attr API - that just means we have a special snowflake for the API rather than a generic way of encoding a name string across all the internal interfaces that space a name/len pair... Really, I was just suggesting using the struct xfs_name because it already exists and encodes/documents exactly what we are passing here, hence getting rid of some of the mess around passing the attr names around. > Also, do I still keep the old reviewed-by on the patch if the patch is still > going through changes? I have a few signed-off patches in the parent > pointer set that have changed quite a bit since we've started too. If the changes are significant, then it needs review again and so you should drop it. But I'd do the name/len -> xfsname conversion as a separate patch, so this patch doesn't need changing. Cheers, Dave. -- Dave Chinner david@fromorbit.com