linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: Steven Whitehouse <swhiteho@redhat.com>,
	David Howells <dhowells@redhat.com>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Al Viro <viro@zeniv.linux.org.uk>, Karel Zak <kzak@redhat.com>,
	Jeff Layton <jlayton@redhat.com>,
	Miklos Szeredi <mszeredi@redhat.com>,
	Nicolas Dichtel <nicolas.dichtel@6wind.com>,
	Christian Brauner <christian@brauner.io>,
	Lennart Poettering <lennart@poettering.net>,
	Linux API <linux-api@vger.kernel.org>,
	Ian Kent <raven@themaw.net>,
	LSM <linux-security-module@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: file metadata via fs API
Date: Tue, 18 Aug 2020 13:53:11 -0700	[thread overview]
Message-ID: <CAHk-=wiUcfgC1PdbS_4mfAj2+VTacOwD_uUu6krSxjpvh42T7A@mail.gmail.com> (raw)
In-Reply-To: <CAJfpegt9yEHX3C-sF9UyOXJcRa1cfDnf450OEJ47Xk=FmyEs8A@mail.gmail.com>

On Tue, Aug 18, 2020 at 1:18 PM Miklos Szeredi <miklos@szeredi.hu> wrote:
>
> So why mix a binary structure into it?  Would it not make more sense
> to make it text only?

.. because for basic and standard stuff, the binary structure just
makes sense and is easier for everybody.

When I want to get the size of a file, I do "stat()" on it, and get
the size from st.st_size. That's convenient, and there's no reason
_not_ to do it. Returning the size as an ASCII string would be
completely pointless and annoying as hell.

So binary formats have their places. But those places are for standard
and well-understood fields that are commonly accessed and do not have
any free-form or wild components to them that needs to be marshalled
into some binary format.

Whenever you have free-form data, just use ASCII.

It's what "mount" already uses, for chrissake. We pass in mount
options as ASCII for a good reason.

Basically, I think a rough rule of thumb can and should be:

 - stuff that the VFS knows about natively and fully is clearly pretty
mount-agnostic and generic, and can be represented in whatever
extended "struct statfs_x" directly.

 - anything that is variable-format and per-fs should be expressed in
the ASCII buffer

Look at our fancy new fs_context - that's pretty much what it does
even inside the kernel. Sure, we have "binary" fields there for core
basic information ("struct dentry *root", but also things like flags
with MNT_NOSUID), but the configuration stuff is ASCII that the
filesystem can parse itself.

Exactly because some things are very much specific to some
filesystems, not generic things.

So we fundamentally already have a mix of "standard FS data" and
"filesystem-specific options", and it's already basically split that
way: binary flag fields for the generic stuff, and ASCII text for the
odd options.

Again: binary data isn't wrong when it's a fixed structure that didn't
need some odd massaging or marshalling or parsing. Just a simple fixed
structure. That is _the_ most common kernel interface, used for almost
everything.  Sometimes we have arrays of them, but most of the time
it's a single struct pointer.

But binary data very much is wrong the moment you think you need to
have a parser to read it, or a marshaller to write it. Just use ASCII.

I really would prefer for the free-form data to have a lot of
commonalities with the /proc/mounts line. Not because that's a
wonderful format, but because there are very very few truly wonderful
formats out there, and in the absense of "wonderful", I'd much prefer
"familiar" and "able to use common helpers" (hopefully both on the
kernel side and the user side)..

               Linus

  reply	other threads:[~2020-08-18 20:53 UTC|newest]

Thread overview: 89+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-03 15:27 [GIT PULL] Mount notifications David Howells
2020-08-03 15:49 ` [GIT PULL] Filesystem Information David Howells
2020-08-03 16:42   ` Miklos Szeredi
2020-08-04  2:15     ` Ian Kent
2020-08-04 14:36       ` Miklos Szeredi
2020-08-05  1:33         ` Ian Kent
2020-08-05  8:00           ` Miklos Szeredi
2020-08-05 11:13             ` Ian Kent
2020-08-05  8:24         ` file metadata via fs API (was: [GIT PULL] Filesystem Information) Miklos Szeredi
2020-08-11 13:54           ` Miklos Szeredi
2020-08-11 14:08             ` Al Viro
2020-08-11 14:22               ` Miklos Szeredi
2020-08-11 14:31                 ` Al Viro
     [not found]                   ` <CAAgocE07=vVKpQhG+rjEGO=NEBKZ02gjg4TRPxECAc+RKrzn=Q@mail.gmail.com>
2020-08-11 14:36                     ` Al Viro
2020-08-11 14:36                   ` Miklos Szeredi
2020-08-11 14:42                     ` Al Viro
2020-08-11 14:47                       ` Miklos Szeredi
2020-08-11 15:20             ` Linus Torvalds
2020-08-11 15:30               ` Miklos Szeredi
2020-08-11 16:05                 ` Linus Torvalds
2020-08-11 18:49                   ` Miklos Szeredi
2020-08-11 19:31                     ` Lennart Poettering
2020-08-11 19:50                       ` Christian Brauner
2020-08-11 19:39                   ` Christian Brauner
2020-08-12  0:53                     ` Ian Kent
2020-08-11 15:39               ` Andy Lutomirski
2020-08-11 16:17                 ` Casey Schaufler
2020-08-11 16:30                   ` Linus Torvalds
2020-08-11 20:28                   ` Miklos Szeredi
2020-08-11 20:36                     ` Jann Horn
2020-08-11 20:56                       ` Miklos Szeredi
2020-08-11 21:17                         ` Andy Lutomirski
2020-08-11 21:18                         ` Linus Torvalds
2020-08-12  7:23                           ` Miklos Szeredi
2020-08-12 14:39                             ` Al Viro
2020-08-12 14:46                               ` Miklos Szeredi
2020-08-12 15:08                                 ` Al Viro
2020-08-12 15:13                                   ` Miklos Szeredi
2020-08-12 16:33                                     ` Al Viro
2020-08-12 17:16                                       ` Miklos Szeredi
2020-08-12 17:39                                         ` Al Viro
2020-08-12 18:33                                           ` Al Viro
2020-08-12 21:30                                             ` Al Viro
2020-08-18  9:41                                               ` Miklos Szeredi
2020-08-18  9:30                                             ` Miklos Szeredi
2020-08-12 15:22                                   ` David Howells
2020-08-11 21:20                     ` Al Viro
2020-08-11 21:35                     ` Casey Schaufler
2020-08-11 16:05               ` Al Viro
2020-08-11 16:09                 ` Linus Torvalds
2020-08-11 16:39                   ` Al Viro
2020-08-12 10:14               ` Karel Zak
2020-08-12 13:09                 ` Miklos Szeredi
2020-08-12 13:33                 ` David Howells
2020-08-12 13:54                   ` Miklos Szeredi
2020-08-12  0:05             ` David Howells
2020-08-12  7:55               ` Miklos Szeredi
2020-08-12  8:29               ` David Howells
2020-08-12  8:37                 ` Miklos Szeredi
2020-08-12  9:43                   ` file metadata via fs API Steven Whitehouse
2020-08-12 10:04                     ` Miklos Szeredi
2020-08-12 11:28                       ` Karel Zak
2020-08-12 12:43                         ` Miklos Szeredi
2020-08-13  8:52                           ` Karel Zak
2020-08-12 13:06                         ` David Howells
2020-08-13  1:01                           ` Ian Kent
2020-08-12 18:18               ` file metadata via fs API (was: [GIT PULL] Filesystem Information) Linus Torvalds
2020-08-12 19:34                 ` file metadata via fs API Steven Whitehouse
2020-08-12 19:50                   ` Linus Torvalds
2020-08-13  3:44                     ` Ian Kent
2020-08-13 10:36                     ` Karel Zak
2020-08-14  7:58                     ` Lennart Poettering
2020-08-17 11:32                     ` Steven Whitehouse
2020-08-17 17:15                       ` Linus Torvalds
2020-08-17 22:44                         ` Linus Torvalds
2020-08-18 12:50                           ` Miklos Szeredi
2020-08-18 18:51                             ` Linus Torvalds
2020-08-18 20:18                               ` Miklos Szeredi
2020-08-18 20:53                                 ` Linus Torvalds [this message]
2020-08-21 13:17                                   ` Miklos Szeredi
2020-08-19  2:29                               ` Al Viro
2020-08-13  3:53                 ` file metadata via fs API (was: [GIT PULL] Filesystem Information) Jeffrey E Altman
2020-08-14 17:05                   ` Linus Torvalds
2020-08-18 15:01                     ` Jeffrey E Altman
2020-08-14  8:06                 ` Lennart Poettering
2020-08-12 13:54             ` David Howells
2020-08-12 14:10               ` Miklos Szeredi
2020-08-12 14:23               ` David Howells
2020-08-03 22:48 ` [GIT PULL] Mount notifications Ian Kent

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='CAHk-=wiUcfgC1PdbS_4mfAj2+VTacOwD_uUu6krSxjpvh42T7A@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=christian@brauner.io \
    --cc=dhowells@redhat.com \
    --cc=jlayton@redhat.com \
    --cc=kzak@redhat.com \
    --cc=lennart@poettering.net \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=mszeredi@redhat.com \
    --cc=nicolas.dichtel@6wind.com \
    --cc=raven@themaw.net \
    --cc=swhiteho@redhat.com \
    --cc=viro@zeniv.linux.org.uk \
    --subject='Re: file metadata via fs API' \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).