Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751557AbdINUYZ (ORCPT ); Thu, 14 Sep 2017 16:24:25 -0400 Received: from mail-it0-f53.google.com ([209.85.214.53]:51592 "EHLO mail-it0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751363AbdINUYX (ORCPT ); Thu, 14 Sep 2017 16:24:23 -0400 X-Google-Smtp-Source: AOwi7QBZnE2MYDTS4/it3cibpqw8w8AYdTWlZSaOk0qtwdMrTocJ5dFg+pVzWamDq26sdK2kiTpj4wqjwH3tN9ZMDeY= MIME-Version: 1.0 In-Reply-To: References: <20170913140528.GA19278@veci.piliscsaba.szeredi.hu> From: Linus Torvalds Date: Thu, 14 Sep 2017 13:24:22 -0700 X-Google-Sender-Auth: esVEQO87bz80ziVPy78CN83idVw Message-ID: Subject: Re: [GIT PULL] overlayfs update for 4.14 To: Miklos Szeredi Cc: Al Viro , Linux Kernel Mailing List , linux-fsdevel , "linux-unionfs@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1013 Lines: 23 On Thu, Sep 14, 2017 at 1:12 PM, Miklos Szeredi wrote: > > I was saying that it's a bad idea to mix external and internal flags. > That was the reason the two were separated on that API. I'm open to > arguments about that. The thing is, I don't think "upper layer" is any more internal than "direct IO" is. And I don't think it's necessarily overlayfs-specific. Other filesystems have potential upper layers (eg things like caching layers, where the "upper" layer could be "the cached copy"). And no, I'm, not saying we should expose things directly to user space. We have lots of operations where we expose some flags to user space but keep others internal (look at the VM_xyz flags for mmap, for example - we obviously expose things like read/write/execute to user space, but we have the MAYREAD/MAYWRITE/MAYEXEC flags in the same word that are *not* something that user space can just set). I just don't see any reason why those two "flags" arguments are separate. Linus