Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933867AbcKKQ2u (ORCPT ); Fri, 11 Nov 2016 11:28:50 -0500 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:44688 "EHLO out4-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756670AbcKKQ2s (ORCPT ); Fri, 11 Nov 2016 11:28:48 -0500 X-ME-Sender: X-Sasl-enc: 73HxYmmYIoQmB2m/W849Xel6CR7ywEg6dZdmGGxTnFvC 1478881727 From: Nikolaus Rath To: Miklos Szeredi Cc: Andrew Gallagher , lkml , linux-fsdevel Subject: Re: commit d7afaec0b564f0609e116f5: fuse: add FUSE_NO_OPEN_SUPPORT flag to INIT References: <87lgwrufuk.fsf@thinkpad.rath.org> <87mvh6likl.fsf@vostro.rath.org> Date: Fri, 11 Nov 2016 08:28:44 -0800 In-Reply-To: (Miklos Szeredi's message of "Fri, 11 Nov 2016 09:43:12 +0100") Message-ID: <87mvh6j803.fsf@thinkpad.rath.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 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-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id uABGSqge031347 Content-Length: 1991 Lines: 47 On Nov 11 2016, Miklos Szeredi wrote: > On Fri, Nov 11, 2016 at 5:57 AM, Nikolaus Rath wrote: >> On Nov 11 2016, Miklos Szeredi wrote: >>> 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. >> >> That doesn't sound like a good approach to me. That way, the file system >> has to *know* that this flag has been introduced in order to behave >> correctly, i.e. filesystems that predate the introduction of the flag >> will suddenly behave differently. >> >> I think the correct behavior would be to for the kernel to check if >> userspace passed the flag, and treat ENOSYS specially if and only if the >> flag was passed. > > ENOSYS is not a valid return value for any existing syscall. Fuse > uses that fact to attach this special meaning to ENOSYS. So > compatibility is not an issue here, old filesystems should never > return ENOSYS from open. Oh, I was under the impression that any FUSE handler is free to return any error it wants. Where does one have to look to determine which return values are valid? Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«