Re: [PATCH][1/7] xattr consolidation - libfs

[Andreas Gruenbacher]

On Tue, 2004-08-24 at 12:05, Christoph Hellwig wrote:
> On Tue, Aug 24, 2004 at 12:32:13AM -0400, James Morris wrote:
> > > limit on the number of xattrs.
> > 
> > Then you can't dynamically regsiter an xattr handler (e.g. as a module).  
> > Is this really desirable?
> 
> IMHO yes.  This is an integral part of the filesystem, and the handlers are
> really small anyway.  And it makes the code really a lot simpler.

Dynamically handler registration seemed a good idea to me when I wrote
the original code, but there never was a real-world user for all I know,
so I'm fine with removing the rwlock. (The rest of the code can stay the
same.)

> > > Also s/simple_// for most symbols as this stuff isn't simple, in fact it's
> > > quite complex :)
> > 
> > Removing the prefix would imply that this was the 'proper' way to
> > implement xattr support.  Really, these are just helper functions for the 
> > simplest xattr implementations.  I think they should have some prefix, but 
> > don't care too much what it actually is.  Suggestions?
> 
> I'd call them generic_.  I've done some research and they should work very
> well for any xattr implementation in the tree.

I would just remove the simple_ to get xattr_register, xattr_unregister,
xattr_resolve_name, xattr_handler.

simple_xattr_list makes no sense in the general case, so this seems to
fit.

If we decide to remove dynamic handler registration, simple_xattr_list
should go as well, and the listxattr iops can enumerate all existing
handlers explicitly.

> [...]

Cheers,
-- 
Andreas Gruenbacher <agruen@xxxxxxx>
SUSE Labs, SUSE LINUX AG


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/