linux-next: manual merge of the rust tree with the vfs-brauner tree

Stephen Rothwell posted 1 patch 1 week, 5 days ago
linux-next: manual merge of the rust tree with the vfs-brauner tree
Posted by Stephen Rothwell 1 week, 5 days ago
Hi all,

Today's linux-next merge of the rust tree got a conflict in:

  rust/kernel/task.rs

between commits:

  e7572e5deaf3 ("rust: types: add `NotThreadSafe`")
  8ad1a41f7e23 ("rust: file: add `Kuid` wrapper")
  e0020ba6cbcb ("rust: add PidNamespace")

from the vfs-brauner tree and commit:

  d072acda4862 ("rust: use custom FFI integer types")

from the rust tree.

I fixed it up (I think - see below) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc rust/kernel/task.rs
index 5120dddaf916,5bce090a3869..000000000000
--- a/rust/kernel/task.rs
+++ b/rust/kernel/task.rs
@@@ -4,17 -4,9 +4,17 @@@
  //!
  //! C header: [`include/linux/sched.h`](srctree/include/linux/sched.h).
  
+ use crate::ffi::{c_int, c_long, c_uint};
 -use crate::types::Opaque;
 -use core::{marker::PhantomData, ops::Deref, ptr};
 +use crate::{
 +    bindings,
 +    pid_namespace::PidNamespace,
 +    types::{ARef, NotThreadSafe, Opaque},
 +};
 +use core::{
 +    cmp::{Eq, PartialEq},
-     ffi::{c_int, c_long, c_uint},
 +    ops::Deref,
 +    ptr,
 +};
  
  /// A sentinel value used for infinite timeouts.
  pub const MAX_SCHEDULE_TIMEOUT: c_long = c_long::MAX;
Re: linux-next: manual merge of the rust tree with the vfs-brauner tree
Posted by Miguel Ojeda 1 week, 4 days ago
On Mon, Nov 11, 2024 at 7:29 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> I fixed it up (I think - see below) and can carry the fix as

Looks good to me -- thanks!

You will get the conflict in the upcoming round again, but this time
without build failures, hopefully! The hash has not changed.

Thanks!

Cheers,
Miguel