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@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. 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
