Re: git: 6b82130e6c9a - main - clock: Add a long ticks variable, ticksl

From: Jessica Clarke <jrtc27_at_freebsd.org>
Date: Fri, 10 Jan 2025 16:59:21 UTC
On 10 Jan 2025, at 16:47, Cy Schubert <Cy.Schubert@cschubert.com> wrote:
> 
> In message <202501101600.50AG0jk6062308@gitrepo.freebsd.org>, Mark Johnston 
> wri
> tes:
>> The branch main has been updated by markj:
>> 
>> URL: https://cgit.FreeBSD.org/src/commit/?id=6b82130e6c9add4a8892ca897df5a0ec
>> 04663ea2
>> 
>> commit 6b82130e6c9add4a8892ca897df5a0ec04663ea2
>> Author:     Mark Johnston <markj@FreeBSD.org>
>> AuthorDate: 2025-01-10 15:37:07 +0000
>> Commit:     Mark Johnston <markj@FreeBSD.org>
>> CommitDate: 2025-01-10 15:42:59 +0000
>> 
>>    clock: Add a long ticks variable, ticksl
>> 
>>    For compatibility with Linux, it's useful to have a tick counter of
>>    width sizeof(long), but our tick counter is an int.  Currently the
>>    linuxkpi tries paper over this difference, but this cannot really be
>>    done reliably, so it's desirable to have a wider tick counter.  This
>>    change introduces ticksl, keeping the existing ticks variable.
>> 
>>    Follow a suggestion from kib to avoid having to maintain two separate
>>    counters and to avoid converting existing code to use ticksl: change
>>    hardclock() to update ticksl instead of ticks, and then use assembler
>>    directives to make ticks and ticksl overlap such that loading ticks
>>    gives the bottom 32 bits.  This makes it possible to use ticksl in the
>>    linuxkpi without having to convert any native code, and without making
>>    hardclock() more complicated or expensive.  Then, the linuxkpi can be
>>    modified to use ticksl instead of ticks.
>> 
>>    Reviewed by:    olce, kib, emaste
>>    MFC after:      1 month
>>    Differential Revision:  https://reviews.freebsd.org/D48383
>> ---
>> sys/conf/files        |  1 +
>> sys/kern/kern_clock.c | 26 ++++++++++++++------------
>> sys/kern/kern_tc.c    |  4 ++--
>> sys/kern/subr_param.c |  2 +-
>> sys/kern/subr_ticks.s | 44 ++++++++++++++++++++++++++++++++++++++++++++
>> sys/sys/kernel.h      |  9 +++++++++
>> sys/sys/timetc.h      |  2 +-
>> 7 files changed, 72 insertions(+), 16 deletions(-)
>> 
> 
> See last paragraph.
> 
> --- kernel.full ---
> linking kernel.full
> ld: error: undefined symbol: ticks
>>>> referenced by cam_iosched.c:1426 (/opt/src/git-src/sys/cam/cam_iosched.c
> :1426)
>>>>              cam_iosched.o:(cam_iosched_put_back_trim)
>>>> referenced by cam_iosched.c:1452 (/opt/src/git-src/sys/cam/cam_iosched.c
> :1452)
>>>>              cam_iosched.o:(cam_iosched_next_trim)
>>>> referenced by cam_iosched.c:823 (/opt/src/git-src/sys/cam/cam_iosched.c:
> 823)
>>>>              cam_iosched.o:(cam_iosched_get_trim)
>>>> referenced 240 more times
>>>> did you mean: tick
>>>> defined in: subr_param.o
> 
> ld: error: undefined symbol: ticksl
>>>> referenced by subr_param.c:200 (/opt/src/git-src/sys/kern/subr_param.c:2
> 00)
>>>>              subr_param.o:(init_param1)
>>>> referenced by kern_clock.c:489 (/opt/src/git-src/sys/kern/kern_clock.c:4
> 89)
>>>>              kern_clock.o:(hardclock)
>>>> referenced by atomic.h:184 (/opt/src/git-src/sys/amd64/include/atomic.h:
> 184)
>>>>              kern_clock.o:(hardclock)
>>>> referenced 1 more times
> *** [kernel.full] Error code 1
> 
> make[2]: stopped making "all" in /export/obj/opt/src/git-src/amd64.amd64/sys
> /BREAK
> make[2]: 1 error
> 
> make[2]: stopped making "all" in /export/obj/opt/src/git-src/amd64.amd64/sys
> /BREAK
>      652.14 real      4727.77 user       227.08 sys
> 
> make[1]: stopped making "buildkernel" in /opt/src/git-src
> 
> make: stopped making "buildkernel" in /opt/src/git-src
> 
> 
> This (failing to link) only occurs with an incremental build; a clean 
> rebuild (of /usr/obj/sys/KERNELNAME) circumvents this error. Should this be 
> noted in UPDATING?

Are you building with KERNFAST / NO_KERNELCONFIG? If so, yeah, that’s
to be expected any time new files are added that are needed by existing
ones. If not, I have no idea how that could possibly happen, this isn’t
the kind of change that depend-cleanup.sh has to care about, and this
kind of change happens all the time.

Jess