All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Andreas Gruenbacher <agruen@suse.de>
Cc: Linux-FSDevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [RFC] Apply the umask in VFS optionally (also POSIX ACL kernel infrastructure)
Date: Mon, 5 Aug 2002 13:24:32 +0100	[thread overview]
Message-ID: <20020805132432.A5301@infradead.org> (raw)
In-Reply-To: <200208051341.28455.agruen@suse.de>; from agruen@suse.de on Mon, Aug 05, 2002 at 01:41:28PM +0200

On Mon, Aug 05, 2002 at 01:41:28PM +0200, Andreas Gruenbacher wrote:
> Well, the previous macro was IS_POSIX_ACL(inode); it was testing a super block 
> flag. We had an additional s_xattr_flags in the super block:

XFS tree is currently a little different:

--- 2.4.19-xfs/include/linux/fs.h
+++ 2.4.19-xfs/include/linux/fs.h
@@ -135,6 +135,7 @@
 #define S_IMMUTABLE	16	/* Immutable file */
 #define S_DEAD		32	/* removed, but still open directory */
 #define S_NOQUOTA	64	/* Inode is not counted to quota */
+#define S_POSIXACL	128	/* Defer applying umask to mode bits */
 
 /*
  * Note that nosuid etc flags are inode-specific: setting some file-system
@@ -163,6 +164,7 @@
 #define IS_NODIRATIME(inode)	__IS_FLG(inode, MS_NODIRATIME)
 
 #define IS_DEADDIR(inode)	((inode)->i_flags & S_DEAD)
+#define IS_POSIXACL(inode)	((inode)->i_flags & S_POSIXACL)
 
 /* the read-only stuff doesn't really belong here, but any other place is
    probably as bad and I don't want to create yet another include file. */
 

Id on't like the per-inode thinkgy, though.  A per-superblock flag
(without s_xattr_flags) is most reasonable in my eyes.

      reply	other threads:[~2002-08-05 12:24 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-08-04 13:46 [RFC] Apply the umask in VFS optionally (also POSIX ACL kernel infrastructure) Andreas Gruenbacher
2002-08-04 14:42 ` Christoph Hellwig
2002-08-05 11:41   ` Andreas Gruenbacher
2002-08-05 12:24     ` Christoph Hellwig [this message]

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=20020805132432.A5301@infradead.org \
    --to=hch@infradead.org \
    --cc=agruen@suse.de \
    --cc=linux-fsdevel@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.