[OpenAFS] Current "balance" practice?

Chaskiel Grundman cg2v@andrew.cmu.edu
Tue, 27 Nov 2018 14:21:21 -0500


>   ubik_VL_SetLock()
>   ubik_VL_ReleaseLock()

> ubik_Call() is no longer used internally by OpenAFS but it is still
> exported.  ubik_Call() relies upon varargs that are unlikely to
> interpret parameter types properly on systems with 64-bit pointers
> and/or size_t.
I'll probably be looking at upgrading balance for our own internal use in
the next month or two, but another ftp.andrew.cmu.edu release is probably
not in the cards (especially since something else I'm doing in the next
few months is retiring ftp.andrew.cmu.edu). Perhaps I'll put it on github.

There is another problem beyond 64-bit safety. It appears that the some of
the openafs devs didn't learn from the project's own experience with the
linux developers, as

extern afs_int32 vsu_ClientInit(int noAuthFlag, const char *confDir,
                                char *cellName, afs_int32 sauth,
                                struct ubik_client **uclientp,
                                int (*secproc)(struct rx_securityClass *,
afs_int32));


in <= 1.6 has become

extern afs_int32 vsu_ClientInit(const char *confDir, char *cellName,
                                int secFlags,
                                int (*secproc)(struct rx_securityClass *,
                                               afs_int32),
                                struct ubik_client **uclientp);


in 1.8. and I can't even use #ifdef VS2SC_NEVER to detect the change --
it's an enum.