Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965289AbcKJXMZ (ORCPT ); Thu, 10 Nov 2016 18:12:25 -0500 Received: from mail-lf0-f42.google.com ([209.85.215.42]:34584 "EHLO mail-lf0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965165AbcKJXMX (ORCPT ); Thu, 10 Nov 2016 18:12:23 -0500 MIME-Version: 1.0 In-Reply-To: <87lgwrufuk.fsf@thinkpad.rath.org> References: <87lgwrufuk.fsf@thinkpad.rath.org> From: Miklos Szeredi Date: Fri, 11 Nov 2016 00:12:20 +0100 Message-ID: Subject: Re: commit d7afaec0b564f0609e116f5: fuse: add FUSE_NO_OPEN_SUPPORT flag to INIT To: Nikolaus Rath Cc: Andrew Gallagher , lkml , linux-fsdevel@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: 918 Lines: 23 On Thu, Nov 10, 2016 at 11:31 PM, Nikolaus Rath wrote: > Hi Andrew, > > In commit d7afaec0b564f0609e116f5 you added a new FUSE_NO_OPEN_SUPPORT > flag. But as far as I can tell, the flag is simply accepted without > having any effect (including in libfuse). > > I tried to find related later commits, but did not find anything either. > > Am I missing something? Hmm, if fuse fs detects this flag, then it can return ENOSYS from open resulting in this and subsequent opens succeeding without further calls to userspace. If fuse fs doesn't detect this flag, it should not return -ENOSYS, as that will result in the open failing, it should instead implement a no-op open method. Could handle this in libfuse and that would make things easier for filesystem implementors that would want to use this feature. But I guess its use is relatively rare and so it doesn't really matter. Thanks, Miklos