From: KP Singh <kpsingh@chromium.org>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Randy Dunlap <rdunlap@infradead.org>,
Stephen Rothwell <sfr@canb.auug.org.au>,
Linux Next Mailing List <linux-next@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
bpf <bpf@vger.kernel.org>
Subject: Re: linux-next: Tree for Mar 5 (bpf_trace)
Date: Thu, 5 Mar 2020 23:04:59 +0100 [thread overview]
Message-ID: <20200305220459.GA29785@chromium.org> (raw)
In-Reply-To: <CAADnVQ+K4Vc2_=tB7COFFBy3uswike-TERoSF=1=GdnWFDUutQ@mail.gmail.com>
On 05-Mär 09:38, Alexei Starovoitov wrote:
> On Thu, Mar 5, 2020 at 9:32 AM KP Singh <kpsingh@chromium.org> wrote:
> >
> > This fails as we added bpf_test_run_tracing in net/bpf/test_run.c
> > which gets built only CONFIG_NET is enabled. Which, this particular
> > config, disables.
> >
> > Alexei, if it's okay with you. I can send a patch that separates the
> > tracing test code into kernel/bpf/test_run_trace.c which depends
> > only on CONFIG_BPF_SYSCALL.
>
> In such situation we typically add __weak dummy call.
I would prefer this. Less chances for breaking something. Sent:
https://lore.kernel.org/bpf/20200305220127.29109-1-kpsingh@chromium.org/T/#u
> May be split will work too.
We can do that separately (if needed).
- KP
> or move tracing_prog_ops to kernel/bpf/core.c ?
next prev parent reply other threads:[~2020-03-05 22:05 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-05 6:55 linux-next: Tree for Mar 5 Stephen Rothwell
2020-03-05 16:13 ` linux-next: Tree for Mar 5 (bpf_trace) Randy Dunlap
2020-03-05 16:18 ` Alexei Starovoitov
2020-03-05 16:22 ` KP Singh
2020-03-05 17:32 ` KP Singh
2020-03-05 17:38 ` Alexei Starovoitov
2020-03-05 22:04 ` KP Singh [this message]
2020-03-05 16:20 ` linux-next: Tree for Mar 5 (staging/media/: rockchip) Randy Dunlap
2020-03-05 16:49 ` linux-next: Tree for Mar 5 (sound/soc/codecs/wcd934x.o) Randy Dunlap
2020-03-05 16:49 ` Randy Dunlap
2020-03-06 12:17 ` Geert Uytterhoeven
2020-03-06 12:17 ` Geert Uytterhoeven
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=20200305220459.GA29785@chromium.org \
--to=kpsingh@chromium.org \
--cc=alexei.starovoitov@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=rdunlap@infradead.org \
--cc=sfr@canb.auug.org.au \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.