> On Apr 21, 2020, at 3:31 AM, Christof Hanke <christof.ha...@mpcdf.mpg.de>
> wrote:
>
> Am Dienstag, 21. April 2020, 09:12:12 CEST schrieb Christof Hanke:
>> Am Dienstag, 21. April 2020, 05:05:45 CEST schrieb Benjamin Kaduk:
>>> On Sat, Apr 18, 2020 at 09:44:24AM +0200, Christof Hanke wrote:
>>>> Hi all,
>>>>
>>>> thanks for the work & updates.
>>>>
>>>> Am Freitag, 17. April 2020, 18:40:47 CEST schrieb Michael Meffie:
>>>>
>>>>>
>>>>> 1.8.x series
>>>>> ============
>>>>>
>>>>> * The Release Team asks developers to refrain from pushing non-critical
>>>>> patches
>>>>> to the openafs-stable-1_8_x branch on gerrit.openafs.org until the 1.8.6
>>>>> release has been finalized.
>>>>>
>>>>> * a9e26acf742cf49e2a773ffbb3f4f62a334950c tagged as
>>>>> openafs-stable-1_8_6pre2
>>>>>
>>>>
>>>> openafs-stable-1_8_6pre2 does not build on a 32Bit architecture.
>>>> Apparently the typedef for "osi_timeval32_t" is missing.
>>>
>>> It seems to be complaining about osi_timeval_t as well as osi_tiemval32_t,
>>> hmm.
>>>
>>> But afs_osi.h should be included before lock.h, and should be providing
>>> those typedefs.
>>>
>> The ifdef in afs_osi.h reads:
>>
>> #if defined(AFS_HPUX_ENV) || defined(AFS_LINUX_64BIT_KERNEL) ||
>> (defined(AFS_SGI61_ENV) && defined(KERNEL) && defined(_K64U64))
>> typedef struct {
>> afs_int32 tv_sec;
>> afs_int32 tv_usec;
>> } osi_timeval_t;
>> typedef struct {
>> afs_int32 tv_sec;
>> afs_int32 tv_usec;
>> } osi_timeval32_t;
>> #elif defined(AFS_SUN5_ENV)
>> typedef struct timeval32 osi_timeval_t;
>> typedef struct timeval32 osi_timeval32_t;
>> #else
>> typedef struct timeval osi_timeval_t;
>> typedef struct timeval osi_timeval32_t;
>> #endif /* AFS_SGI61_ENV */
>>
>>
>> Thus, for a 32bit-machine, osi_timeval[32]_t is defined as "struct timeval"
>>
>> In the Linux-kernel log
>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/include/linux/time.h?h=v5.6.5&id=5dbf20127f8cca8588ad0b0e3e8ded587ac7afa0
>> it says:
>>
>> [...snip..]
>> Interfaces based on 'struct timespec' or 'struct timeval' should no
>> longer be used for new code, which can use either ktime_t or 'struct
>> timespec64' instead.
>>
>> To make this a little clearer, this moves the various helpers into a new
>> time32.h header. For the moment, this gets included by the normal time.h,
>> but we may be able to separate it entirely when most users of time32.h
>> are gone.
>> [..snip...]
>>
>> I come to this below again.
>>
>>> I guess it looks like we don't have any 32-bit linux builders in the 1.8.x
>>> triggered build list, though, and possibly not any 32-bit linux builders
>>> that are active at all (https://buildbot.openafs.org/#/builders).
>>
>> The builder opensuse-tumbleweed-i386
>> e.g.
>>
>> https://buildbot.openafs.org/#/builders/34/builds/1459/steps/6/logs/stdio
>>
>> is showing the same problem.
>>
>>
>>>
>>> That said, the 32-bit builds for debian of 1.8.6pre1 have gone through
>>> fine, so we don't seem to be completely broken.
>> Looking at the header file "linux/time.h" for opensuse-tumbleweed,
>> time32.h is no longer included. Therefore the type "struct timeval" is no
>> longer defined
>> This might be the difference between debian and opensuse.
>>
> no, I was wrong here, time32.h is still included, but somehow the "struct
> timeval" is gone.
>
The problem here is that the conditionals in afs_osi.h for osi_timeval_t and
osi_timeval32_t
need updating. The intent is that we only define them explicitly as 32-bit for
platforms that we know
have a 64-bit 'timeval'; otherwise, we default to native implementations we
"know" to be 32-bit.
But this is a moving target, and has been for some time. In Christof's case,
I presume that arch
i586 forces a 32-bit kernel, so AFS_LINUX_64BIT_KERNEL is undefined. This
results in a fallthrough
to the default case which typedef's osi_timeval_t to (native Linux) timeval.
However, this timeval no longer exists on y2038-compliant Linux kernels. So a
fix is
definitely needed here.
For a different-but-related osi_timeval_t problem in UKERNEL based code, I am
currently working
on ways to improve our osi_timeval_t definitions. I will keep this problem in
mind as well;
perhaps I can kill two birds with one stone.
--
Mark Vitale
mvit...@sinenomine.net
_______________________________________________
OpenAFS-devel mailing list
OpenAFS-devel@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-devel
