Re: [PATCH v2] KVM: selftests: Replace ulong with unsigned long

On 8/19/26 00:28, Sean Christopherson wrote:
> +David for the VFIO thing
> 
> On Tue, Aug 18, 2026, Hisam Mehboob wrote:
>> On 8/18/26 21:27, Sean Christopherson wrote:
>>
>>> Oh, so on top of "https://github.com/kvm-x86/linux.git next", this *is* the last
>>> blocker?  If so, then I'll grab this for 7.3.
>>
>> Not quite -- I tested kvm-x86/next + this patch with musl-gcc, and the
>> build still fails. On top of the steal_time fix already in your tree,
>> two more musl blockers remain, both from code that is only in
>> kvm-x86/next so far:
>>
>> 1. hardware_disable_test.c, from 496779b54943 ("Pre-set threads affinity
>>     in hardware disable test when possible"):
>>
>>       hardware_disable_test.c:75: error: implicit declaration of function
>>       'pthread_attr_setaffinity_np'
>>
>>     The call sits under #ifdef _GNU_SOURCE, but lib.mk defines _GNU_SOURCE
>>     unconditionally, so the path is always taken and musl (which lacks the
>>     function) breaks.
> 
> Heh, Sashiko flagged that as problematic, and I was trying to figure out which
> macro to key off of[*], but was (obviously) unsuccessful.  I don't suppose you
> know the canonical way for checking for support of glibc-only functionality of
> this nature?
> 
> [*] https://lore.kernel.org/all/[email protected]
> 

__GLIBC__ is the pragmatic in-tree answer.
_GNU_SOURCE is a request macro (input to the libc headers), not an
availability indicator -- lib.mk defines it unconditionally, so it
cannot detect anything. __USE_GNU works but is glibc-internal.
__GLIBC__ is defined by glibc's <features.h>, which any libc header
pulls in, and is the established idiom in selftests already:
kvm/lib/assert.c uses "#ifdef __GLIBC__" for execinfo.h, as do
bpf/test_progs.c and nolibc. musl deliberately provides no __MUSL__ --
its FAQ's stance is "test for properties, don't assume them", which
strictly implies a compile test (autoconf-style); with no configure
step in selftests, __GLIBC__ is the established in-tree idiom. For
hardware_disable_test.c that is s/_GNU_SOURCE/__GLIBC__/ in the three
spots; build-tested with musl-gcc, passes.

>>
>> 2. The libvfio wiring from a262fc49e0aa ("Build and link
>>     selftests/vfio/lib into KVM selftests"):
>>
>>       vfio_pci_device.c:25: fatal error: uuid/uuid.h: No such file or
>> directory
>>       sysfs.c:31: error: implicit declaration of function 'basename'
>>
>>     The former adds a hard libuuid dependency (its headers aren't visible
>>     to musl-gcc here);
> 
> Can you elaborate on what you mean by "its headers aren't visible to musl-gcc"?

musl-gcc searches only its own include directories
(here: /usr/include/x86_64-linux-musl and gcc's internal dir) and
deliberately not /usr/include, to avoid mixing glibc-oriented headers
with musl. uuid/uuid.h comes from libuuid (util-linux) and is installed
at /usr/include/uuid/uuid.h for the glibc toolchain, so glibc builds
find it and musl builds cannot. I see 2f0c30d0d1 already limits the
libvfio link to x86; the remaining gap on x86 is that libuuid is now a
hard dependency of the KVM selftests build (libvfio.mk adds -luuid),
and for musl-x86 the header is not visible at all without a
musl-targeted libuuid install. A uuid.h compile check to skip the vfio
pieces would keep it optional; otherwise the new dependency is probably
worth documenting.

> 
>>     the latter because musl declares basename only in
>>     <libgen.h>, while glibc exposes it via <string.h> under _GNU_SOURCE.
> 
> IIUC, sysfs.c just needs to explicitly include libgen.h?

Yes, adding <libgen.h> suffices. One nuance: there are two
flavors -- glibc under _GNU_SOURCE provides the GNU variant via
<string.h> (char *basename(const char *), non-modifying), while
<libgen.h> provides the POSIX variant (char *basename(char *), may
modify) and takes precedence on glibc as well. Safe at this call site:
rl_path is a writable buffer filled by readlink() (no trailing
slashes), used once by sscanf(). Verified with compile tests on both
libcs, and with <libgen.h> added, uuid/uuid.h is the only remaining
musl failure in the whole build.

>> The rseq __GNUC_PREREQ failure is already covered by my patch in
>> linux-next. With the above sorted, the musl build passes.