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
| ||
|
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