All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: David Howells <dhowells@redhat.com>
Cc: Christoph Hellwig <hch@infradead.org>,
	linux-fsdevel@vger.kernel.org, linux-afs@vger.kernel.org,
	linux-nfs@vger.kernel.org, samba-technical@lists.samba.org,
	linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org
Subject: Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available
Date: Tue, 10 May 2016 00:08:03 -0700	[thread overview]
Message-ID: <20160510070803.GC30896@infradead.org> (raw)
In-Reply-To: <1734.1462801101@warthog.procyon.org.uk>

On Mon, May 09, 2016 at 02:38:21PM +0100, David Howells wrote:
> Let's look at the list, and please bear in mind I'm trying to make it so that
> you can emulate stat() through this interface.  If you want to waive that
> requirement - or push the emulation out to userspace - then I can forego
> providing unsupported data from the basic stat set.

why would you want to emulate stat?

> | (0) st_information, st_dev_*, st_blksize.
> 
> st_dev_* and st_blksize must always be available from whatever we stat.
> Because this is the case, there's no point providing mask bits for them.
> 
> My implementation defines st_information to be in this class, but it doesn't
> have to be.  Note that st_information really needs a way to ask the filesystem
> what flags it actually supports so that you can distinguish being 0 -> not set
> from 0 -> not supported, hence the fsinfo() interface that I've dropped for
> now.

All of these are easily available.  But why special case them so that
userspace must not ask for them?  This makes an otherwise totally
regular interface special now.  Note that filesystems could always fill
it out anyway and set it in the return mask.

> | (1) st_nlinks, st_uid, st_gid, st_[amc]time*, st_ino, st_size, st_blocks.
> 
> These data are all in the bog standard struct stat.  As it is, they must all
> be given values as for stat().  However, mask bits are provided to indicate
> when the value presented here is actually fabricated so that the user can
> decide not to use them.

Next special case..

> | (2) st_mode.
> 
> This is actually in two parts.  There's the file type (which must always be
> set correctly) and the mode bits (which may be fabricated).  STATX_MODE covers
> the mode bits only.

Next special case.

> 
> | (3) st_rdev_*.
> 
> This datum is part of the bog standard struct stat, and as such must be set to
> something.  However, the value is only relevant in the case that the mode
> indicates a blockdev or chardev.  STATX_RDEV can be considered redundant in
> such a case.
> 
> | (4) File creation time (st_btime*), data version (st_version), inode
> |     generation number (st_gen).
> 
> These are all new data and have no counterpart in the Linux struct stat.
> However, they do in the struct stat on other Unix variants (st_birthtime and
> st_gen, for example, exist on BSD).  Not all filesystems provide them so if
> they are requested but are not actually supported by a filesystem, the bit in
> the mask is cleared upon returning.
> 
> However, even if you didn't ask for a datum, it may still be available - and I
> am permitting a filesystem to give you the datum and mark the mask to indicate
> the value's availability, even if you didn't ask for it.  You are free to
> ignore it.

I think the fs may return it anyway case is fine, but let's make that
a 100% generic thing and not special case fields.

> At this time, I think it likely that all new attributes would be in this
> class.  One could argue that something like st_win_attrs (in patch 5) could be
> in class 0 if added immediately, but anything added later *must* have a mask
> bit to indicate its presence.
> 
> 
> So, barring st_information, classes (0) - (3) are all current stat stuff.
> That is how they work *now*.  All I'm doing is defining which data have mask
> bits, and under what conditions the mask bit might not be set.

Who cares about stat?  You are adding a new system call and are not
bound by what certain versions of stat did at specific points in time.

  reply	other threads:[~2016-05-10  7:08 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-29 12:57 [RFC][PATCH 0/6] Enhanced file stat system call David Howells
2016-04-29 12:57 ` [PATCH 1/6] statx: Add a system call to make enhanced file info available David Howells
2016-05-02 22:46   ` Andreas Dilger
2016-05-02 22:46     ` Andreas Dilger
2016-05-03 15:53   ` David Howells
2016-05-04 22:56   ` Dave Chinner
2016-05-05  0:09     ` NeilBrown
2016-05-05  0:09       ` NeilBrown
2016-05-05 19:48       ` Jeff Layton
2016-05-06 18:07         ` J. Bruce Fields
2016-05-06 18:07           ` J. Bruce Fields
2016-05-05 20:04       ` David Howells
2016-05-05 20:04         ` David Howells
2016-05-06  1:39         ` Dave Chinner
2016-05-06  1:39           ` Dave Chinner
2016-05-06  1:39           ` Dave Chinner
2016-05-06 18:29     ` J. Bruce Fields
2016-05-09  1:45       ` Dave Chinner
2016-05-09  2:46         ` J. Bruce Fields
2016-05-04 23:56   ` NeilBrown
2016-05-08  8:35   ` Christoph Hellwig
2016-05-08  8:35     ` Christoph Hellwig
2016-05-09 12:02     ` Jeff Layton
2016-05-09 12:02       ` Jeff Layton
2016-05-10  7:00       ` Christoph Hellwig
2016-05-10  7:00         ` Christoph Hellwig
2016-05-10 13:21         ` Jeff Layton
2016-05-10 13:21           ` Jeff Layton
2016-05-09 12:57   ` David Howells
2016-05-09 12:57     ` David Howells
2016-05-09 13:23     ` Trond Myklebust
2016-05-09 13:23       ` Trond Myklebust
2016-05-09 13:23       ` Trond Myklebust
2016-05-10  7:04     ` Christoph Hellwig
2016-05-10  8:25     ` David Howells
2016-05-12  9:11       ` Christoph Hellwig
2016-05-13 15:28         ` Arnd Bergmann
2016-05-13 15:28           ` Arnd Bergmann
2016-05-23  8:22           ` Christoph Hellwig
2016-05-23  9:33           ` David Howells
2016-05-18 10:55         ` David Howells
2016-05-09 13:00   ` David Howells
2016-05-09 13:00     ` David Howells
2016-05-09 13:38   ` David Howells
2016-05-10  7:08     ` Christoph Hellwig [this message]
2016-05-10  8:43     ` David Howells
2016-05-12  9:12       ` Christoph Hellwig
2016-05-09 13:40   ` David Howells
2016-04-29 12:57 ` [PATCH 2/6] statx: AFS: Return enhanced file attributes David Howells
2016-04-29 12:57 ` [PATCH 3/6] statx: Ext4: " David Howells
2016-05-02 22:48   ` Andreas Dilger
2016-05-03 20:24   ` David Howells
2016-05-03 20:24     ` David Howells
2016-05-08  8:38   ` Christoph Hellwig
2016-05-08  8:38     ` Christoph Hellwig
2016-04-29 12:58 ` [PATCH 4/6] statx: NFS: " David Howells
2016-05-02 22:48   ` Andreas Dilger
2016-04-29 12:58 ` [PATCH 5/6] statx: Make windows attributes available for CIFS, NTFS and FAT to use David Howells
2016-05-02 22:52   ` Andreas Dilger
2016-10-03 21:03     ` Steve French
2016-10-03 21:03       ` Steve French
2016-05-03 20:23   ` David Howells
2016-05-08  8:39   ` Christoph Hellwig
2016-05-08  8:39     ` Christoph Hellwig
2016-04-29 12:58 ` [PATCH 6/6] statx: CIFS: Return enhanced attributes David Howells
2016-04-30 21:05 ` [RFC][PATCH 0/6] Enhanced file stat system call Jeff Layton
2016-04-30 21:05   ` Jeff Layton
2016-05-04 13:46 ` Arnd Bergmann
2016-05-04 13:46   ` Arnd Bergmann
2016-05-05 22:54   ` Steve French
2016-05-06  2:00     ` Steve French
2016-05-09 13:09       ` Arnd Bergmann
2016-05-09 13:09         ` Arnd Bergmann
2016-05-13 14:28         ` Richard Sharpe
2016-05-13 14:28           ` Richard Sharpe
2016-05-13 15:08           ` Arnd Bergmann

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=20160510070803.GC30896@infradead.org \
    --to=hch@infradead.org \
    --cc=dhowells@redhat.com \
    --cc=linux-afs@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=samba-technical@lists.samba.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.