VFS - ENOTSUP vs ENOSYS

[Ira Cooper]

Jeremy Allison <jra at samba.org> writes:

> On Thu, Sep 03, 2015 at 03:02:07PM +0200, Michael Adam wrote:
>> Yeah, for a given share connection (i.e. connected vfs stack).
>> 
>> > ENOTSUP implies there may be another fd or whatever where
>> > it could work.
>> 
>> 
>> > Given that we support multiple VFS modules, it is hard for me to see
>> > many cases where we'd return ENOSYS in reality.
>> > 
>> > Now, I do consider this an ABI change, and one which may break modules
>> > not in tree.  (Will?)
>> > 
>> > I'd really like feedback on this before I start looking at how to fix
>> > it.  ENOTSUP is a proposed errno for this situation.  If people have
>> > other ideas, I'm all ears.
>> 
>> I think this line of thoughts sounds like a reasonable set of
>> changes. And if this is how to fix some problems, and this
>> requires a VFS (ABI) change, then so be it. But that's just me.
>> ;-)
>
> I think returning ENOTSUP in this case is a reasonable change.

To be clear:

There is no global "The system doesn't support this call." return.
ENOSYS makes no sense its traditional meaning.  Think of a Linux system
that is exporting a XFS filesystem on one share, and a GlusterFS
filesystem on another path.

So I propose:

ENOSYS - This VFS instantiation (stack) does not support this call.
ENOTSUP - This call is not supported at this time, a change in the call
or what it is on, may make it succeed.

I'd like to align our VFS returns and checks with these meanings.

Thanks,

-Ira