On Wed, Nov 13, 2019 at 11:57 PM Xiao Yang <ice_yangxiao@xxxxxxx> wrote:
>
> On 11/13/19 4:54 PM, Masahiro Yamada wrote:
> > On Wed, Nov 13, 2019 at 5:36 PM Xiao Yang <ice_yangxiao@xxxxxxx> wrote:
> >> On 11/13/19 3:53 PM, Masahiro Yamada wrote:
> >>> On Wed, Nov 13, 2019 at 4:17 PM Xiao Yang <ice_yangxiao@xxxxxxx> wrote:
> >>>> On 11/13/19 2:57 PM, Masahiro Yamada wrote:
> >>>>> Sorry, I really do not understand what you are doing.
> >>>>>
> >>>>> include/linux/compiler.h is only for kernel-space.
> >>>>> Shrug if a user-land program includes it.
> >>>> Hi Masahiro,
> >>>>
> >>>> For building tools/bpf, it is good to fix the compiler error by Daniel's
> >>>> patch(i.e. use linux/filter from linux header).
> >>>>
> >>>> linux/compiler.h may be used by other code in kernel. Is it possible to
> >>>> trigger the same error when the other code
> >>>>
> >>>> including linux/compiler.h is built? Is this kind of code able to find
> >>>> the location of <asm/rwonce.h>?
> >>> <asm/rwonce.h> is also kernel-only header.
> >>>
> >>> The kernel code can find <asm/rwonce.h>, but user-land code cannot.
> >> Hi Masahiro,
> >>
> >> Sorry, I am not familar with it.
> >>
> >> Thanks a lot for your explanation and I have seen the LINUXINCLUDE
> >> variable in Makefile.
> >>
> >> I will try to send a patch as Daniel suggested.
> >>
> >> Best Regards,
> >>
> >> Xiao Yang
> >>
> > Hmm, digging into the git history,
> > this include path was added by the following commit:
> >
> >
> > commit d7475de58575c904818efa369c82e88c6648ce2e
> > Author: Kamal Mostafa <kamal@xxxxxxxxxxxxx>
> > Date: Wed Nov 11 14:24:27 2015 -0800
> >
> > tools/net: Use include/uapi with __EXPORTED_HEADERS__
> >
> > Use the local uapi headers to keep in sync with "recently" added #define's
> > (e.g. SKF_AD_VLAN_TPID). Refactored CFLAGS, and bpf_asm doesn't need -I.
> >
> > Fixes: 3f356385e8a4 ("filter: bpf_asm: add minimal bpf asm tool")
> > Signed-off-by: Kamal Mostafa <kamal@xxxxxxxxxxxxx>
> > Acked-by: Daniel Borkmann <daniel@xxxxxxxxxxxxx>
> > Signed-off-by: David S. Miller <davem@xxxxxxxxxxxxx>
> >
> >
> >
> > I am not sure how big a deal it is,
> > but it could be a problem on old distros??
> >
> Hi Daniel, Masahiro
>
>
> Could we include the linux/filter.h generated by "make headers_install"
> as a higher priority?
>
> (PS: According to above commit, just ensure that tools/bpf keeps in sync
> with new linux header as far as possible).
>
> and then use the linux/filter.h in system if kernel doesn't provide
> linux/filter.h by "make headers_install".
>
> --------------------------------------------------------------------------------------------------------------------
>
> diff --git a/tools/bpf/Makefile b/tools/bpf/Makefile
> index 5d1995fd369c..1e0c768132af 100644
> --- a/tools/bpf/Makefile
> +++ b/tools/bpf/Makefile
> @@ -10,7 +10,7 @@ MAKE = make
> INSTALL ?= install
>
> CFLAGS += -Wall -O2
> -CFLAGS += -D__EXPORTED_HEADERS__ -I$(srctree)/include/uapi
> -I$(srctree)/include
> +CFLAGS += -I$(srctree)/usr/include
Probably, this does not work for O= build.
And, you also need to run 'make headers' somewhere
because usr/include does not contain any header in a clean state.
Be careful, people always tend to break out-of-tree build.
I recommend to double, triple check it.
(I believe this is a horrible design mistake
of the tools build system.)
> # This will work when bpf is built in tools env. where srctree
> # isn't set and when invoked from selftests build, where srctree
>
> ---------------------------------------------------------------------------------------------------------------------
>
>
> Best Regards,
>
> Xiao Yang
>
> >
>
--
Best Regards
Masahiro Yamada
