From: David Howells <email@example.com> To: Christoph Hellwig <firstname.lastname@example.org> Cc: email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com Subject: Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available Date: Mon, 09 May 2016 14:38:21 +0100 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <20160508083543.GA14316@infradead.org> Christoph Hellwig <email@example.com> wrote: > How are the semantics defined when userspace asks for fields not > available? I'd expect them to be ignored, but we should documentat that > fact. I went into this in some detail. > > Fields in struct statx come in a number of classes: > > I really disagree with all these special cases. You should get > what you ask for, or rather what you ask for IFF the fs can provide it. > And we need to document for each field if it's optional if we want > to treat it as option. I did document this. You saw it as a bunch of special cases. It is not. stat() fabricates some of the data it returns under certain circumstances. > A hodge podge bag of special cases is not an API that a normal person can > use. 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. | (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. | (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. | (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. | (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. 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. David
next prev parent reply other threads:[~2016-05-09 13:38 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 [this message] 2016-05-10 7:08 ` Christoph Hellwig 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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available' \ /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
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.