Netdev List
 help / color / mirror / Atom feed
From: David Miller <davem@davemloft.net>
To: qinteng@fb.com
Cc: peterz@infradead.org, bgregg@netflix.com, daniel@iogearbox.net,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	Kernel-team@fb.com, ast@fb.com
Subject: Re: [PATCH net-next] bpf: update perf event helper function signature and documentation
Date: Thu, 25 May 2017 12:07:35 -0400 (EDT)	[thread overview]
Message-ID: <20170525.120735.2136402827310294315.davem@davemloft.net> (raw)
In-Reply-To: <BB53B290-EED3-4B92-8D2D-33954D7B6C68@fb.com>

From: Teng Qin <qinteng@fb.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.


      reply	other threads:[~2017-05-25 16:07 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-23  0:39 [PATCH net-next] bpf: update perf event helper function signature and documentation Teng Qin
2017-05-23  3:08 ` David Miller
2017-05-23  3:17   ` Teng Qin
2017-05-25 16:07     ` David Miller [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170525.120735.2136402827310294315.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=Kernel-team@fb.com \
    --cc=ast@fb.com \
    --cc=bgregg@netflix.com \
    --cc=daniel@iogearbox.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=qinteng@fb.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox