public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: James Morris <jmorris@redhat.com>
Cc: Christoph Hellwig <hch@infradead.org>,
	Andrew Morton <akpm@osdl.org>,
	viro@parcelfarce.linux.theplanet.co.uk,
	Stephen Smalley <sds@epoch.ncsc.mil>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH][1/7] xattr consolidation - libfs
Date: Tue, 24 Aug 2004 11:05:55 +0100	[thread overview]
Message-ID: <20040824110555.A27385@infradead.org> (raw)
In-Reply-To: <Xine.LNX.4.44.0408240026460.17851-100000@thoron.boston.redhat.com>; from jmorris@redhat.com on Tue, Aug 24, 2004 at 12:32:13AM -0400

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.

> 
> > 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.  As I mentioned in the
previous mail I'd like to get rid of the old inode operations for xattrs
completely in the long-term (I had been researching this before your patch
because I wanted to get rid of the access control checks in the filesystem
that are inherent with theses)


  reply	other threads:[~2004-08-24 10:07 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-23 18:14 [PATCH][0/7] xattr consolidation and support for ramfs & tmpfs James Morris
2004-08-23 18:15 ` [PATCH][1/7] xattr consolidation - libfs James Morris
2004-08-23 18:16   ` [PATCH][2/7] xattr consolidation - LSM hook changes James Morris
2004-08-23 18:17     ` [PATCH][3/7] xattr consolidation - ext3 James Morris
2004-08-23 18:18       ` [PATCH][4/7] xattr consolidation - ext2 James Morris
2004-08-23 18:19         ` [5/7] xattr consolidation - devpts James Morris
2004-08-23 18:20           ` [PATCH][6/7] add xattr support to tmpfs James Morris
2004-08-23 18:22             ` [PATCH][7/7] add xattr support to ramfs James Morris
2004-08-23 20:26               ` Christoph Hellwig
2004-08-23 20:26                 ` Stephen Smalley
2004-08-23 20:46                   ` Christoph Hellwig
2004-08-23 20:59                   ` Greg KH
2004-08-23 21:27                     ` [PATCH][7/7] add xattr support to ramfs [u] Martin Schlemmer [c]
2004-08-24  0:52                     ` [PATCH][7/7] add xattr support to ramfs Valdis.Kletnieks
2004-08-24 11:27                     ` Stephen Smalley
2004-08-25  7:03                       ` Miles Bader
2004-08-25 13:14                         ` James Morris
2004-08-23 19:06             ` [PATCH][6/7] add xattr support to tmpfs Christoph Hellwig
2004-08-23 19:03     ` [PATCH][2/7] xattr consolidation - LSM hook changes Christoph Hellwig
2004-08-23 19:06       ` James Morris
2004-08-23 19:13       ` Stephen Smalley
2004-08-24  0:54         ` James Morris
2004-08-24  2:52           ` viro
2004-08-24 19:27             ` Andreas Gruenbacher
2004-08-23 23:28       ` Andreas Dilger
2004-08-23 18:49   ` [PATCH][1/7] xattr consolidation - libfs Christoph Hellwig
2004-08-24  4:32     ` James Morris
2004-08-24 10:05       ` Christoph Hellwig [this message]
2004-08-24 19:42         ` Andreas Gruenbacher
2004-08-24 20:19           ` James Morris
2004-08-24 19:41 ` [PATCH][0/7] xattr consolidation and support for ramfs & tmpfs Andreas Gruenbacher

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040824110555.A27385@infradead.org \
    --to=hch@infradead.org \
    --cc=akpm@osdl.org \
    --cc=jmorris@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sds@epoch.ncsc.mil \
    --cc=viro@parcelfarce.linux.theplanet.co.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox