netdev - Re: bpf-next experiment

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAADnVQKNULb55aFOt1Di53Crf64TvF6p7upvUxLwSbrgMw=puw@mail.gmail.com>
Date: Thu, 15 Aug 2024 15:01:33 +0200
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Toke Høiland-Jørgensen <toke@...hat.com>
Cc: bpf <bpf@...r.kernel.org>, Network Development <netdev@...r.kernel.org>, 
	Linus Torvalds <torvalds@...ux-foundation.org>, Jonathan Corbet <corbet@....net>, 
	Stephen Rothwell <sfr@...b.auug.org.au>, Daniel Borkmann <daniel@...earbox.net>, 
	Andrii Nakryiko <andrii@...nel.org>, Martin KaFai Lau <martin.lau@...nel.org>, 
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, 
	"David S. Miller" <davem@...emloft.net>, Eric Dumazet <eric.dumazet@...il.com>
Subject: Re: bpf-next experiment

On Thu, Aug 15, 2024 at 12:15 PM Toke Høiland-Jørgensen <toke@...hat.com> wrote:
>
> Alexei Starovoitov <alexei.starovoitov@...il.com> writes:
>
> > 2. Non-networking bpf commits land in bpf-next/master branch.
> > It will form bpf-next PR during the merge window.
> >
> > 3. Networking related commits (like XDP) land in bpf-next/net branch.
> > They will be PR-ed to net-next and ffwded from net-next
> > as we do today. All these patches will get to mainline
> > via net-next PR.
>
> So from a submitter PoV, someone submitting an XDP-related patch (say),
> should base this off of bpf-next/net, and tag it as bpf-next in the
> subject? Or should it also be tagged as bpf-next/net?

This part we're still figuring out.
There are few considerations...
it's certainly easier for bpf CI when the patch set
is tagged with [PATCH bpf-next/net] then CI won't try
to find the branch,
but it will take a long time to teach all contributors
to tag things differently,
so CI would need to get smart anyway and would need
to apply to /master, run tests, apply to /net, run tests too.
Currently when there is no tag CI attempts to apply to bpf.git,
if it fails, it tries to apply to bpf-next/master and only
then reports back "merge conflict".
It will do this for bpf, bpf-next/master, bpf-next/net now.

Sometimes devs think that the patch is a fix, so they
tag it with [PATCH bpf], but it might not be,
and after review we apply it to bpf-next instead.

So tree/branch to base patches off and tag don't
matter that much.
So I hope, in practice, we won't need to teach all
developers about new tag and about new branch.
We certainly won't be asking to resubmit if patches
are not tagged one way or the other,
but if you want to help CI and tell maintainers
your preferences then certainly start using
[PATCH bpf-next] and [PATCH bpf-next/net] when necessary.
Or don't :) and instead help us make CI smarter :)