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
> >>
>> 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
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
> >
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,
>
> 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
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 )
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