[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFyMvt2Nc6s99BbzTSpFBJt6ekdfsi4Le2sCU0LGb-6RLg@mail.gmail.com>
Date: Wed, 5 Jul 2017 14:51:43 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Al Viro <viro@...iv.linux.org.uk>, Christoph Hellwig <hch@....de>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [git pull] vfs.git part 3
On Wed, Jul 5, 2017 at 12:14 AM, Al Viro <viro@...iv.linux.org.uk> wrote:
>
> Christoph's fs/read_write.c series - consolidation and cleanups.
Side note - when looking through this, it struck me how confusing that
"int flags" argument was.
We have a ton of "flags" in the filesystem layer, and how all the
read/write helpers take them too, and it's really hard to see what
kind of flags they are.
Could we perhaps make those RWF_xyz flags have a nice bitwise type,
and use that type in the argument list, so that not only could there
be some sparse typechecking, but the functions that pass flags on to
each other would automatically have a certain amount of actual
self-documenting prototypes?
So when you look at one of those vfs_iter_write() or whatever
functions, you just see *what* flags the flags argument is.
Because "int flags" really is the worst. It's the wrong type anyway
(at least make it unsigned if it's a collection of bits), but it's
also very ambiguous indeed when there are so many other flags that are
often used/tested in the same functions (there's the "iter" flagsm,
there's file->f_mode, there's just a lot of different flags going on,
and the "int flags" is the least well documented of them all,
particularly since 99.9% of all users just pass in zero).
Hmm?
Linus
Powered by blists - more mailing lists