All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexei Starovoitov <ast@plumgrid.com>
To: Ingo Molnar <mingo@kernel.org>
Cc: "David S. Miller" <davem@davemloft.net>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Wang Nan <wangnan0@huawei.com>, He Kuang <hekuang@huawei.com>,
	Kaixu Xia <xiakaixu@huawei.com>,
	Daniel Borkmann <daniel@iogearbox.net>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next] bpf: make tracing helpers gpl only
Date: Sun, 25 Oct 2015 11:17:58 -0700	[thread overview]
Message-ID: <562D1CD6.6020307@plumgrid.com> (raw)
In-Reply-To: <20151025091411.GE24337@gmail.com>

On 10/25/15 2:14 AM, Ingo Molnar wrote:
> so I don't know the netfilter ones, but in particular the tracing ones I'm sure
> should be gpl-only. Do we really, really want proprietary modules mucking with
> such internals??

of course, not. Therefore bpf_probe_read() was gpl_only from very
beginning. Same goes to bpf_trace_printk() and bpf_ktime_get_ns().
and after this patch the only remaining non-gpl tracing helpers will be
bpf_get_current_pid_tgid()/uid_gid()/comm()
and imo it's fine.

On the networking side the helpers are non-gpl, since all of them are
generic. They don't mess with kernel, but examine/modify the packet.
Just like cBPF can read the packet data, get_processor_id, get_random,
eBPF can do the same plus write into the packet, compute checksum,
redirect, push/pop vlan.

When we introduce eBPF for seccomp, I would argue that helpers on that
side should be non-gpl as well, otherwise people will try to add
features to cBPF instead of moving to eBPF.


  reply	other threads:[~2015-10-25 18:18 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-23 21:58 [PATCH net-next] bpf: make tracing helpers gpl only Alexei Starovoitov
2015-10-25  9:14 ` Ingo Molnar
2015-10-25 18:17   ` Alexei Starovoitov [this message]
2015-10-27  4:54 ` David Miller

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=562D1CD6.6020307@plumgrid.com \
    --to=ast@plumgrid.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=hekuang@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=wangnan0@huawei.com \
    --cc=xiakaixu@huawei.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 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.