Re: [PATCH v3] tools/dma: move dma_map_benchmark from selftests to tools/dma

[Qinxin Xia <xiaqinxin@huawei.com>]

On 2025/10/21 14:23:40, Barry Song <21cnbao@gmail.com> wrote:
> On Tue, Oct 21, 2025 at 6:16 PM Qinxin Xia <xiaqinxin@huawei.com> wrote:
>>
>>
>>
>> On 2025/10/21 10:59:05, Barry Song <21cnbao@gmail.com> wrote:
>>>> @@ -0,0 +1,2 @@
>>>> +# SPDX-License-Identifier: GPL-2.0-only
>>>> +dma_map_benchmark
>>>> diff --git a/tools/dma/Makefile b/tools/dma/Makefile
>>>> new file mode 100644
>>>> index 000000000000..4acbd9e00cfa
>>>> --- /dev/null
>>>> +++ b/tools/dma/Makefile
>>>> @@ -0,0 +1,17 @@
>>>> +# SPDX-License-Identifier: GPL-2.0
>>>> +bindir ?= /usr/bin
>>>> +
>>>> +CFLAGS += -idirafter../../include/uapi
>>>
>>> I'm a bit confused — it seems you haven’t tried to understand what the issue
>>> was in v1 [1]. You were using -I for kernel header files (under
>>> include/linux but not uapi), which caused those kernel headers to take
>>> precedence over the system headers, leading to build errors. The uapi
>>> headers, however, are specifically designed to be installed into the system by
>>> the toolchain.
>>> So that’s no longer the case — -idirafter is not the correct flag for uapi.
>>>
>> Hello Barry :
>> If I delete -idirafter, like:
>>
>> CFLAGS += -I../../include/uapi
>>
>> It will get warning info:
>>
>> [xiaqinxin@localhost dma]$ make
>> cc -I../../include/uapi dma_map_benchmark.c -o dma_map_benchmark
>> In file included from ../../include/uapi/linux/map_benchmark.h:9,
>>                    from dma_map_benchmark.c:13:
>> ../../include/uapi/linux/types.h:10:2: warning: #warning "Attempt to use
>> kernel headers from user space, see https://kernelnewbies.org/
>> KernelHeaders" [-Wcpp]
>>      10 | #warning "Attempt to use kernel headers from user space, see
>> https://kernelnewbies.org/KernelHeaders"
>>
>> So I keep -idirafter there.
>>
>> There's another way, like:
>>
>> CFLAGS += -I../../usr/include
>> (need make headers_install first)
>>
>> Maybe I haven’t thought it through.
>> If you have a better way, you can give an example.:)
> 
> I see — the uapi headers haven’t been installed yet. This issue will
> automatically resolve once the toolchain is upgraded. Before that, we
> can try the following:
> 
> tools/gpio/Makefile
> 
> #
> # We need the following to be outside of kernel tree
> #
> $(OUTPUT)include/linux/gpio.h: ../../include/uapi/linux/gpio.h
>          mkdir -p $(OUTPUT)include/linux 2>&1 || true
>          ln -sf $(CURDIR)/../../include/uapi/linux/gpio.h $@
> 
> prepare: $(OUTPUT)include/linux/gpio.h
> 
> I guess we could copy and paste GPIO’s Makefile and make a few minor
> modifications?
> 
>>
>>>> index b12f1f9babf8..5474a450863c 100644
>>>> --- a/tools/testing/selftests/dma/dma_map_benchmark.c
>>>> +++ b/tools/dma/dma_map_benchmark.c
>>>> @@ -10,7 +10,6 @@
>>>>    #include <unistd.h>
>>>>    #include <sys/ioctl.h>
>>>>    #include <sys/mman.h>
>>>> -#include <linux/types.h>
>>>
>>> What’s the reason for this? Is it to work around a build error?
>>> If so, no — please keep it.
>>>
>>>>    #include <linux/map_benchmark.h>
>>>
>>
>> Moved it to map_benchmark.h, otherwise some x86_64 build errors
>> would occur.
> 
> Let’s avoid moving types.h — that feels more like a workaround than a
> proper fix.
> 
> Thanks
> Barry
Hello Barry:

Sorry, I don't think it a workaround.When kernel builds with
'CONFIG_UAPI_HEADER_TEST=y'. The build system will checks on the
user space API header files in the usr/include directory.
The header file must be compiled independently.

'__u32' '__u64' in map_benchmark.h depends on the definition of linux/
types.h. If map_benchmark.h does not include types.h,there will lead to
hdrtest error.

That's why I do that.