Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Wed, 18 Jul 2018 12:31:53 -0400
From:   Jan Harkes <jaharkes@cs.cmu.edu>
To:     Arnd Bergmann <arnd@arndb.de>
Cc:     "open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Linux FS-devel Mailing List <linux-fsdevel@vger.kernel.org>,
        Jonathan Corbet <corbet@lwn.net>,
        Deepa Dinamani <deepa.kernel@gmail.com>
Subject: Re: [PATCH] [RESEND] coda: stop using 'struct timespec' in user API
Message-ID: <20180718163153.ogfriudjw7ztwpag@cs.cmu.edu>
Mail-Followup-To: Arnd Bergmann <arnd@arndb.de>,
        "open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Linux FS-devel Mailing List <linux-fsdevel@vger.kernel.org>,
        Jonathan Corbet <corbet@lwn.net>,
        Deepa Dinamani <deepa.kernel@gmail.com>
References: <20180718114645.591551-1-arnd@arndb.de>
 <20180718155006.lkoktldllafrfqbf@cs.cmu.edu>
 <CAK8P3a3HYBar1yVCEjxR2VNpPOOx23qM5fCyO-TMmeF780rBiQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAK8P3a3HYBar1yVCEjxR2VNpPOOx23qM5fCyO-TMmeF780rBiQ@mail.gmail.com>
User-Agent: NeoMutt/20180512
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, Jul 18, 2018 at 06:10:29PM +0200, Arnd Bergmann wrote:
> On Wed, Jul 18, 2018 at 5:50 PM, Jan Harkes <jaharkes@cs.cmu.edu> wrote:
> > On Wed, Jul 18, 2018 at 01:46:25PM +0200, Arnd Bergmann wrote:
> >> Unfortunately, this breaks the layout of the coda_vattr structure, so
> >> we need to redefine that in terms of something that does not change.
> >> I'm introducing a new 'struct vtimespec' structure here that keeps
> >> the existing layout, and the same change has to be done in the coda
> >> user space copy of linux/coda.h before anyone can use that on a 32-bit
> >> architecture with 64-bit time_t.
> >
> > I think the userbase is small enough that we can handle a much simpler
> > transition to 64-bit timespecs everywhere. In that case the
> > CODA_KERNEL_VERSION should be updated, which is currently defined in
> > include/uapi/linux/coda.h as 3. As moving to 64-bit timespecs only
> > breaks 32-bit systems this allows userspace to catch that case and
> > refuse to run userspace with a mismatched layout (or handle
> > translation).
> 
> Ok, so to make sure I get this right, you say we can do an
> incompatible ABI change for coda without causing any problems
> for existing users?
> 
> That would definitely be the easiest approach here. I guess
> we also just have to be incompatible for 32-bit user space,
> since it would make 32-bit users have the same ABI as 64-bit
> ones, right?
> 
> I'll have another look at the ABI side then, to see how it can
> be transitioned.

Correct, the first thing a client does after opening the /dev/cfs0
device is to send a CIOC_KERNEL_VERSION ioctl. In response the Coda
kernel module returns the current value of CODA_KERNEL_VERSION.

Right now anything but 3 will make the client complain about version
mismatch and refuse to start. It is trivial to allow existing 64-bit
clients to accept both 3 and 4 as valid, and when 32-bit userspace is
updated to also use 64-bit timespec it can be changed to accept only 4.

> >> > If we only have one code base, it should be fairly straightforward to
> >> > make it deal with 'unsigned' timestamps consistently, which would
> >> > let the code work fine until 2106 rather than wrapping around from
> >> > 2038 to 1902.
> >
> > At some point there was a webdav filesystem that used the Coda kernel
> > apis, but I think they may have moved to FUSE since then so I would not
> > be surprised if there is only a single code base at this point.
> 
> Ok, I found davfs2 at http://dav.sourceforge.net/index.shtml
> 
> Ah, so the coda kernel implementation is similar to both fuse and 9pfs
> in that it can connect to arbitrary user space implementations, but with
> no known users other than your coda user space and some versions of
> davfs2?

Correct and since the FUSE api is easier to work with it has seen more
users. AFAIK, the work on davfs2 was started before FUSE existed.

Jan