On Wed, Jul 18, 2018 at 5:50 PM, Jan Harkes [off-list ref] wrote:

On Wed, Jul 18, 2018 at 01:46:25PM +0200, Arnd Bergmann wrote:

quoted

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.

quoted

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.

quoted

quoted

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
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html