Prev: KVM: MMU: combine guest pte read between walk and pte prefetch
Next: [PATCH] Break out types from <linux/list.h> to <linux/list_types.h>.
From: Andreas Dilger on 2 Jul 2010 13:50
On 2010-07-01, at 17:57, David Howells wrote:
> [This is, for the moment, to be considered an example. Do we actually want to
> export these flags? Should they be a full member of struct xstat?]

I would say this should be a full-fledged member of struct xstat. I think they are fairly standard (available on many filesystems today), and requiring an ioctl to access them is unpleasant.

> (1) User settable flags (to be consistent with the BSD st_flags field):
>
> UF_NODUMP Do not dump this file.
> UF_IMMUTABLE This file is immutable.
> UF_APPEND This file is append-only.
> UF_OPAQUE This directory is opaque (unionfs).
> UF_NOUNLINK This file can't be removed or renamed.
> UF_COMPRESSED This file is compressed.
> UF_HIDDEN This file shouldn't be displayed in a GUI.
>
> The UF_SETTABLE constant is the union of the above flags.
>
> (2) Superuser settable flags (to be consistent with the BSD st_flags field):
>
> SF_ARCHIVED This file has been archived.
> SF_IMMUTABLE This file is immutable.
> SF_APPEND This file is append-only.
> SF_NOUNLINK This file can't be removed or renamed.
> SF_HIDDEN This file is a snapshot inode.
>
> The SF_SETTABLE constant is the union of the above flags.
>
> (3) Linux-specific flags:
>
> XSTAT_LF_MAGIC_FILE Magic file, such as found in procfs and sysfs.
> XSTAT_LF_SYNC File is written synchronously.
> XSTAT_LF_NOATIME Atime is not updated on this file.
> XSTAT_LF_JOURNALLED_DATA Data modifications to this file are journalled.
> XSTAT_LF_ENCRYPTED This file is encrypted.
> XSTAT_LF_SYSTEM This file is a system file (FAT/NTFS/CIFS).
> XSTAT_LF_TEMPORARY This file is a temporary file (NTFS/CIFS).
> XSTAT_LF_OFFLINE file is currently unavailable (CIFS).

Yuck on the names. Why not stick with the "UF_" and "SF_" prefixes? Since we don't need to keep _binary_ compatibility with these flag values (only name portability) we can use the same flag values as the FS_*_FL definitions in fs.h. That is what all of the existing filesystems already use (ext2/3/4, ocfs, btrfs, reiserfs, xfs, jfs).

Cheers, Andreas





--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: David Howells on 5 Jul 2010 11:10
Andreas Dilger <adilger(a)dilger.ca> wrote:

> I would say this should be a full-fledged member of struct xstat. I think
> they are fairly standard (available on many filesystems today), and
> requiring an ioctl to access them is unpleasant.

Remember: adding them to xstat and kstat will use up three extra 64-bit words
of stack at least if ecryptfs.

Are they used often enough to justify this?

> Yuck on the names. Why not stick with the "UF_" and "SF_" prefixes?

Firstly, this is a quick and dirty example, primarily because I'd like someone
to take a look at the mechanism.

Secondly, because the flags I've added don't have UF_ and SF_ variants within
Linux.

> Since we don't need to keep _binary_ compatibility with these flag values
> (only name portability) we can use the same flag values as the FS_*_FL
> definitions in fs.h.

No, you can't, because Linux doesn't have separate S and U variants.

However, I'd be quite happy to just use the FS_*_FL, perhaps plus a couple of
flags, and have userspace munge together the BSD-compatible st_flags. To that
end, could we rearrange i_flags to match the ioctl?

David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 | 
Pages: 1
Prev: KVM: MMU: combine guest pte read between walk and pte prefetch
Next: [PATCH] Break out types from <linux/list.h> to <linux/list_types.h>.