Messages in this thread |  | | | Subject | Re: [PATCH][1/7] xattr consolidation - libfs | | From | Andreas Gruenbacher <> | | Date | Tue, 24 Aug 2004 21:42:53 +0200 |
| |
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@suse.de> SUSE Labs, SUSE LINUX AG
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |