netdev - Re: [PATCH net-next v7 3/5] rust: add second `bindgen` pass for enum exhaustiveness checking

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: Windows password security audit tool. GUI, reports in PDF.

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

Date: Fri, 27 Oct 2023 12:50:21 +0200
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: FUJITA Tomonori <fujita.tomonori@...il.com>, netdev@...r.kernel.org, 
	rust-for-linux@...r.kernel.org, tmgross@...ch.edu, benno.lossin@...ton.me, 
	wedsonaf@...il.com, ojeda@...nel.org
Subject: Re: [PATCH net-next v7 3/5] rust: add second `bindgen` pass for enum
 exhaustiveness checking

On Fri, Oct 27, 2023 at 2:07 AM Andrew Lunn <andrew@...n.ch> wrote:
>
> That is not how netdev works. It messes up the patch flow, since the
> machinery expects to commit all or nothing.

Then please simply drop this patch (or improve the machinery :)

> The best way forwards is you create a stable branch with this
> patch. The netdev Maintainer can then pull that branch into netdev,
> and Tomonori can then add his patches using it on top. When everything
> meets up in linux-next, git then recognises it has the same patch
> twice and drops one of them, depending on the order of the merge.

That is only needed if you want to land all this in the next cycle, do
you? Moreover, it also assumes this exhaustiveness check lands -- it
has not been posted/discussed/agreed yet.

Thus, if either of those are false, then this bit (or the entire
series) could just wait one cycle.

> That does not work. Networking patches need to be on net-next.

I have not said the patches should not go through net-next, though.
And what I suggested definitely works.

> The
> stable branch solves that when we have cross subsystem dependencies.

Yes, we are aware of that, thank you. We are even doing it right now
with another subsystem.

Cheers,
Miguel