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: <feb34b35-e847-43f4-824f-157b1b96c7f0@lunn.ch>
Date: Fri, 27 Oct 2023 02:07:37 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
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 Thu, Oct 26, 2023 at 02:22:23PM +0200, Miguel Ojeda wrote:
> On Thu, Oct 26, 2023 at 1:54 PM FUJITA Tomonori
> <fujita.tomonori@...il.com> wrote:
> >
> > Sorry, I totally misunderstand your intention. I thought that the PHY
> > abstractions needs to be merged with your patch together.
> >
> > I'll drop your patch in the next version and focus on my patches.
> 
> No harm done! I understand you were trying to help, and I apologize if
> I sounded too harsh.
> 
> Your abstractions are not blocked on this patch -- they could go in
> without this, that is why I suggested marking this one as RFC and
> putting it at the end of the series.

That is not how netdev works. It messes up the patch flow, since the
machinery expects to commit all or nothing.

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.

> I will send the patch soon, and assuming it lands, then you can start
> using the feature if you wish. I would recommend basing your patches
> on top of that patch (or `rust-next` when the patch lands),

That does not work. Networking patches need to be on net-next. The
stable branch solves that when we have cross subsystem dependencies.

       Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ