Re: [PATCH] [RESEND] coda: stop using 'struct timespec' in user API

Re: [PATCH] [RESEND] coda: stop using 'struct timespec' in user API

[Arnd Bergmann]

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.

> It also would make how to handle questions about truncation moot, or at
> least moves the problem out of the kernel into userspace.  We actually
> were already using unsigned integers for timestamps in the client <->
> server protocol, so as you noted, that does give us a little breather
> until 2106.

ok.

>> Originally sent on June 19, which lead to a short discussion
>> and an Ack, but the patch did not get picked up for 4.19 yet.
>
> I'm sorry, somehow I missed the follow up questions in that discussion.
>
>> > 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?

      Arnd

Re: [PATCH] [RESEND] coda: stop using 'struct timespec' in user API

[Jan Harkes]

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