[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20170525.120735.2136402827310294315.davem@davemloft.net>
Date: Thu, 25 May 2017 12:07:35 -0400 (EDT)
From: David Miller <davem@...emloft.net>
To: qinteng@...com
Cc: peterz@...radead.org, bgregg@...flix.com, daniel@...earbox.net,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
Kernel-team@...com, ast@...com
Subject: Re: [PATCH net-next] bpf: update perf event helper function
signature and documentation
From: Teng Qin <qinteng@...com>
Date: Tue, 23 May 2017 03:17:31 +0000
> Alexei said it was due to Clang not taking u64, u32 etc. for compilation.
> I didn’t know the context and just used them. But apparently, something
> changed and now they build and run OK......
These types are %100 compiler agnostic. Clang doesn't care. All
compilers can understand:
typedef unsigned int u32;
So it's not a Clang specific issue.
The problem could only have to do with whether the types get typdef'd
or not with the header files that are used in conjunction with the
file we are talking about here.
And if we do get a proper set of defines from linux/types.h these days
we should:
1) Make that explicit, by including linux/types.h in bpf_helpers.h
2) Use those types universally in this file where we were avoiding
doing so
This header file also uses "SEC" and expects to get this definition
implicitly, and therefore there is another header file that
bpf_helpers.h must include in order to explicitly and reliably have
that definition.
Just changing one prototype, and relying on getting the types
indirectly by other header files including by whoever incudes
bpf_helpers.h is not the way to go.
Thanks.
Powered by blists - more mailing lists