Re: [OpenAFS] Current "balance" practice?
On Sat, Dec 01, 2018 at 04:29:29AM +, Chaskiel Grundman wrote: > >> The vsu_ClientInit() signature change was a side-effect of the > >> refactoring of ugen_ClientInit(). No one remembered the possible out of > >> tree usage of vsu_ClientInit(). vsu_ClientInit() is not an exported > >> function. As such its status as public is murky at best. > > > >Indeed, I use the export symbol lists for the public shared libraries to > >determine what standard of review to apply to API changes, and non-exported > >symbols mostly get a free-for-all for API changes. > > If that's how the world works, then commit to it, and don't publish the > related archive libraries or headers anymore. I guess this is already in > progress, as the prototypes for UV_* functions used by balance and backup > clients (in volser_prototypes.h and volser_internal.h) are not part of > distributions. It's definitely something to think about for 2.0, yes. > The "public" shared libraries started life as "what the threaded fileserver > and windows processes running in the service manager need from > rx/rxkad/des/comerr" and "what the threaded fileserver needed from afsconf" + > "what libadmin needed from the kaserver client". Only people who really cared > about getting rid of LWP would have tried to migrate to them from the old > archive libraries. Fair points all. Thanks, Ben ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Current "balance" practice?
>> The vsu_ClientInit() signature change was a side-effect of the >> refactoring of ugen_ClientInit(). No one remembered the possible out of >> tree usage of vsu_ClientInit(). vsu_ClientInit() is not an exported >> function. As such its status as public is murky at best. > >Indeed, I use the export symbol lists for the public shared libraries to >determine what standard of review to apply to API changes, and non-exported >symbols mostly get a free-for-all for API changes. If that's how the world works, then commit to it, and don't publish the related archive libraries or headers anymore. I guess this is already in progress, as the prototypes for UV_* functions used by balance and backup clients (in volser_prototypes.h and volser_internal.h) are not part of distributions. The "public" shared libraries started life as "what the threaded fileserver and windows processes running in the service manager need from rx/rxkad/des/comerr" and "what the threaded fileserver needed from afsconf" + "what libadmin needed from the kaserver client". Only people who really cared about getting rid of LWP would have tried to migrate to them from the old archive libraries.___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Current "balance" practice?
On Tue, Nov 27, 2018 at 04:51:54PM -0500, Jeffrey Altman wrote: > On 11/27/2018 2:21 PM, Chaskiel Grundman wrote: > > 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. > > That would be AuriStor's fault. The change in question was > > commit 3720f6b646857cca523659519f6fd4441e41dc7a > Author: Simon Wilkinson > Date: Sun Oct 23 16:21:52 2011 +0100 > > Rework the ugen_* interface > > The vsu_ClientInit() signature change was a side-effect of the > refactoring of ugen_ClientInit(). No one remembered the possible out of > tree usage of vsu_ClientInit(). vsu_ClientInit() is not an exported > function. As such its status as public is murky at best. Indeed, I use the export symbol lists for the public shared libraries to determine what standard of review to apply to API changes, and non-exported symbols mostly get a free-for-all for API changes. > I suggest using the existence of one of these CPP macros as a test. > They were added shortly after the vsu_ClientInit() signature change was > merged. > > /* Values for the UV_ReleaseVolume flags parameters */ > #define REL_COMPLETE0x01 /* force a complete release */ > #define REL_FULLDUMPS 0x02 /* force full dumps */ > #define REL_STAYUP 0x04 /* dump to clones to avoid offline > time */ > > The introduction of enum vol_s2s_crypt came much later. > > If you would prefer AuriStor can submit a change to restore the prior > signature. That said, I do not subscribe to the philosophy of "aggressively break APIs not documented as stable", and would likely merge such a change if there was demand for it. (But I leave it to Chaskiel et al to express such a demand, if one is indeed present.) -Ben ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Current "balance" practice?
On 11/27/2018 2:21 PM, Chaskiel Grundman wrote: > 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. That would be AuriStor's fault. The change in question was commit 3720f6b646857cca523659519f6fd4441e41dc7a Author: Simon Wilkinson Date: Sun Oct 23 16:21:52 2011 +0100 Rework the ugen_* interface The vsu_ClientInit() signature change was a side-effect of the refactoring of ugen_ClientInit(). No one remembered the possible out of tree usage of vsu_ClientInit(). vsu_ClientInit() is not an exported function. As such its status as public is murky at best. I suggest using the existence of one of these CPP macros as a test. They were added shortly after the vsu_ClientInit() signature change was merged. /* Values for the UV_ReleaseVolume flags parameters */ #define REL_COMPLETE0x01 /* force a complete release */ #define REL_FULLDUMPS 0x02 /* force full dumps */ #define REL_STAYUP 0x04 /* dump to clones to avoid offline time */ The introduction of enum vol_s2s_crypt came much later. If you would prefer AuriStor can submit a change to restore the prior signature. Jeffrey Altman <> smime.p7s Description: S/MIME Cryptographic Signature
Re: [OpenAFS] Current "balance" practice?
> 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. ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Current "balance" practice?
On 10/19/2018 11:04 AM, Jonathan Proulx wrote: > Hi All, > > We're currently running a sightly hacked up version of balance-1.1a (I > belvieve originally from ftp://ftp.andrew.cmu.edu/pub/AFS-Tools/ ) on > a old 32bit linux server ( well 32bit kernel and userland hardware > under it is 64bit ) with openafs 1.6.1 > > Shockingly this seesm to still work, but I'm trying kill off the > oldest straggling servers and neither copying the binary (and using > 32bit libs ) nor recompiling it seems to work on new 64bit OS with > openafs 1.8.2 The "balance" sources date back to IBM 3.4 or earlier and relies upon ubik_Call() instead of 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. Unless there are other 64-bit safety issues within balance itself, switching to ubik_VL_SetLock() and ubik_VL_ReleaseLock() might be sufficient. > I've also noticed that the Wiki points to an abandoned perl > implementation from 2007 > ( https://www.eyrie.org/~eagle/software/afs-balance/ ) Although similarly named Russ Allbery's balance which was developed at Stanford is unrelated to Dan Lovinger's balance. Russ' balance can make decisions based upon volume count and volume size whereas Dan's can make decisions based upon weekly volume usage as well. Jeffrey Altman <> smime.p7s Description: S/MIME Cryptographic Signature
