On Wed, Jul 18, 2018 at 5:50 PM, Jan Harkes <jaharkes@xxxxxxxxxx> 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
