* linux-next: manual merge of the pwm tree with the modules tree
@ 2025-11-03 23:48 Stephen Rothwell
2025-11-03 23:54 ` Stephen Rothwell
0 siblings, 1 reply; 9+ messages in thread
From: Stephen Rothwell @ 2025-11-03 23:48 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Andreas Hindborg, Daniel Gomez, Linux Kernel Mailing List,
Linux Next Mailing List, Michal Wilczynski
[-- Attachment #1: Type: text/plain, Size: 5281 bytes --]
Hi all,
FIXME: Add owner of second tree to To:
Add author(s)/SOB of conflicting commits.
Today's linux-next merge of the pwm tree got a conflict in:
rust/macros/module.rs
between commits:
3809d7a89fe5 ("rust: module: use a reference in macros::module::module")
0b24f9740f26 ("rust: module: update the module macro with module parameter support")
from the modules tree and commit:
927687809649 ("rust: macros: Add support for 'imports_ns' to module!")
from the pwm tree.
I followed a supplied resolution from Uwe and Danieli, thanks. Though I
am just wondering (fromfollowing the pattern) if the "&ns" on line 545
should be "ns" - though I guess it would fail to build if so?
I fixed it up (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/macros/module.rs
index d62e9c1e2a89,408cd1154875..000000000000
--- a/rust/macros/module.rs
+++ b/rust/macros/module.rs
@@@ -205,50 -98,7 +205,51 @@@ struct ModuleInfo
description: Option<String>,
alias: Option<Vec<String>>,
firmware: Option<Vec<String>>,
+ imports_ns: Option<Vec<String>>,
+ params: Option<Vec<Parameter>>,
+}
+
+#[derive(Debug)]
+struct Parameter {
+ name: String,
+ ptype: String,
+ default: String,
+ description: String,
+}
+
+fn expect_params(it: &mut token_stream::IntoIter) -> Vec<Parameter> {
+ let params = expect_group(it);
+ assert_eq!(params.delimiter(), Delimiter::Brace);
+ let mut it = params.stream().into_iter();
+ let mut parsed = Vec::new();
+
+ loop {
+ let param_name = match it.next() {
+ Some(TokenTree::Ident(ident)) => ident.to_string(),
+ Some(_) => panic!("Expected Ident or end"),
+ None => break,
+ };
+
+ assert_eq!(expect_punct(&mut it), ':');
+ let param_type = expect_ident(&mut it);
+ let group = expect_group(&mut it);
+ assert_eq!(group.delimiter(), Delimiter::Brace);
+ assert_eq!(expect_punct(&mut it), ',');
+
+ let mut param_it = group.stream().into_iter();
+ let param_default = expect_param_default(&mut param_it);
+ let param_description = expect_string_field(&mut param_it, "description");
+ expect_end(&mut param_it);
+
+ parsed.push(Parameter {
+ name: param_name,
+ ptype: param_type,
+ default: param_default,
+ description: param_description,
+ })
+ }
+
+ parsed
}
impl ModuleInfo {
@@@ -263,7 -113,7 +264,8 @@@
"license",
"alias",
"firmware",
+ "imports_ns",
+ "params",
];
const REQUIRED_KEYS: &[&str] = &["type", "name", "license"];
let mut seen_keys = Vec::new();
@@@ -289,7 -139,7 +291,8 @@@
"license" => info.license = expect_string_ascii(it),
"alias" => info.alias = Some(expect_string_array(it)),
"firmware" => info.firmware = Some(expect_string_array(it)),
+ "imports_ns" => info.imports_ns = Some(expect_string_array(it)),
+ "params" => info.params = Some(expect_params(it)),
_ => panic!("Unknown key \"{key}\". Valid keys are: {EXPECTED_KEYS:?}."),
}
@@@ -329,25 -179,30 +332,30 @@@ pub(crate) fn module(ts: TokenStream) -
// Rust does not allow hyphens in identifiers, use underscore instead.
let ident = info.name.replace('-', "_");
let mut modinfo = ModInfoBuilder::new(ident.as_ref());
- if let Some(authors) = info.authors {
+ if let Some(authors) = &info.authors {
for author in authors {
- modinfo.emit("author", &author);
+ modinfo.emit("author", author);
}
}
- if let Some(description) = info.description {
- modinfo.emit("description", &description);
+ if let Some(description) = &info.description {
+ modinfo.emit("description", description);
}
modinfo.emit("license", &info.license);
- if let Some(aliases) = info.alias {
+ if let Some(aliases) = &info.alias {
for alias in aliases {
- modinfo.emit("alias", &alias);
+ modinfo.emit("alias", alias);
}
}
- if let Some(firmware) = info.firmware {
+ if let Some(firmware) = &info.firmware {
for fw in firmware {
- modinfo.emit("firmware", &fw);
+ modinfo.emit("firmware", fw);
}
}
- if let Some(imports) = info.imports_ns {
++ if let Some(imports) = &info.imports_ns {
+ for ns in imports {
+ modinfo.emit("import_ns", &ns);
+ }
+ }
// Built-in modules also export the `file` modinfo string.
let file =
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: linux-next: manual merge of the pwm tree with the modules tree 2025-11-03 23:48 linux-next: manual merge of the pwm tree with the modules tree Stephen Rothwell @ 2025-11-03 23:54 ` Stephen Rothwell 2025-11-04 8:48 ` Daniel Gomez 2025-11-07 16:44 ` Uwe Kleine-König 0 siblings, 2 replies; 9+ messages in thread From: Stephen Rothwell @ 2025-11-03 23:54 UTC (permalink / raw) To: Uwe Kleine-König, Luis Chamberlain, Daniel Gomez, Sami Tolvanen, Petr Pavlu Cc: Andreas Hindborg, Daniel Gomez, Linux Kernel Mailing List, Linux Next Mailing List, Michal Wilczynski [-- Attachment #1: Type: text/plain, Size: 5634 bytes --] Hi all, [adding the modules tree contacts] On Tue, 4 Nov 2025 10:48:27 +1100 Stephen Rothwell <sfr@canb•auug.org.au> wrote: > > Today's linux-next merge of the pwm tree got a conflict in: > > rust/macros/module.rs > > between commits: > > 3809d7a89fe5 ("rust: module: use a reference in macros::module::module") > 0b24f9740f26 ("rust: module: update the module macro with module parameter support") > > from the modules tree and commit: > > 927687809649 ("rust: macros: Add support for 'imports_ns' to module!") > > from the pwm tree. > > I followed a supplied resolution from Uwe and Danieli, thanks. Though I > am just wondering (fromfollowing the pattern) if the "&ns" on line 545 > should be "ns" - though I guess it would fail to build if so? > > I fixed it up (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/macros/module.rs > index d62e9c1e2a89,408cd1154875..000000000000 > --- a/rust/macros/module.rs > +++ b/rust/macros/module.rs > @@@ -205,50 -98,7 +205,51 @@@ struct ModuleInfo > description: Option<String>, > alias: Option<Vec<String>>, > firmware: Option<Vec<String>>, > + imports_ns: Option<Vec<String>>, > + params: Option<Vec<Parameter>>, > +} > + > +#[derive(Debug)] > +struct Parameter { > + name: String, > + ptype: String, > + default: String, > + description: String, > +} > + > +fn expect_params(it: &mut token_stream::IntoIter) -> Vec<Parameter> { > + let params = expect_group(it); > + assert_eq!(params.delimiter(), Delimiter::Brace); > + let mut it = params.stream().into_iter(); > + let mut parsed = Vec::new(); > + > + loop { > + let param_name = match it.next() { > + Some(TokenTree::Ident(ident)) => ident.to_string(), > + Some(_) => panic!("Expected Ident or end"), > + None => break, > + }; > + > + assert_eq!(expect_punct(&mut it), ':'); > + let param_type = expect_ident(&mut it); > + let group = expect_group(&mut it); > + assert_eq!(group.delimiter(), Delimiter::Brace); > + assert_eq!(expect_punct(&mut it), ','); > + > + let mut param_it = group.stream().into_iter(); > + let param_default = expect_param_default(&mut param_it); > + let param_description = expect_string_field(&mut param_it, "description"); > + expect_end(&mut param_it); > + > + parsed.push(Parameter { > + name: param_name, > + ptype: param_type, > + default: param_default, > + description: param_description, > + }) > + } > + > + parsed > } > > impl ModuleInfo { > @@@ -263,7 -113,7 +264,8 @@@ > "license", > "alias", > "firmware", > + "imports_ns", > + "params", > ]; > const REQUIRED_KEYS: &[&str] = &["type", "name", "license"]; > let mut seen_keys = Vec::new(); > @@@ -289,7 -139,7 +291,8 @@@ > "license" => info.license = expect_string_ascii(it), > "alias" => info.alias = Some(expect_string_array(it)), > "firmware" => info.firmware = Some(expect_string_array(it)), > + "imports_ns" => info.imports_ns = Some(expect_string_array(it)), > + "params" => info.params = Some(expect_params(it)), > _ => panic!("Unknown key \"{key}\". Valid keys are: {EXPECTED_KEYS:?}."), > } > > @@@ -329,25 -179,30 +332,30 @@@ pub(crate) fn module(ts: TokenStream) - > // Rust does not allow hyphens in identifiers, use underscore instead. > let ident = info.name.replace('-', "_"); > let mut modinfo = ModInfoBuilder::new(ident.as_ref()); > - if let Some(authors) = info.authors { > + if let Some(authors) = &info.authors { > for author in authors { > - modinfo.emit("author", &author); > + modinfo.emit("author", author); > } > } > - if let Some(description) = info.description { > - modinfo.emit("description", &description); > + if let Some(description) = &info.description { > + modinfo.emit("description", description); > } > modinfo.emit("license", &info.license); > - if let Some(aliases) = info.alias { > + if let Some(aliases) = &info.alias { > for alias in aliases { > - modinfo.emit("alias", &alias); > + modinfo.emit("alias", alias); > } > } > - if let Some(firmware) = info.firmware { > + if let Some(firmware) = &info.firmware { > for fw in firmware { > - modinfo.emit("firmware", &fw); > + modinfo.emit("firmware", fw); > } > } > - if let Some(imports) = info.imports_ns { > ++ if let Some(imports) = &info.imports_ns { > + for ns in imports { > + modinfo.emit("import_ns", &ns); > + } > + } > > // Built-in modules also export the `file` modinfo string. > let file = -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: linux-next: manual merge of the pwm tree with the modules tree 2025-11-03 23:54 ` Stephen Rothwell @ 2025-11-04 8:48 ` Daniel Gomez 2025-11-04 21:17 ` Stephen Rothwell 2025-11-07 16:44 ` Uwe Kleine-König 1 sibling, 1 reply; 9+ messages in thread From: Daniel Gomez @ 2025-11-04 8:48 UTC (permalink / raw) To: Stephen Rothwell, Uwe Kleine-König, Luis Chamberlain, Daniel Gomez, Sami Tolvanen, Petr Pavlu Cc: Andreas Hindborg, Linux Kernel Mailing List, Linux Next Mailing List, Michal Wilczynski On 04/11/2025 00.54, Stephen Rothwell wrote: > Hi all, > > [adding the modules tree contacts] > > On Tue, 4 Nov 2025 10:48:27 +1100 Stephen Rothwell <sfr@canb•auug.org.au> wrote: >> >> Today's linux-next merge of the pwm tree got a conflict in: >> >> rust/macros/module.rs >> >> between commits: >> >> 3809d7a89fe5 ("rust: module: use a reference in macros::module::module") >> 0b24f9740f26 ("rust: module: update the module macro with module parameter support") >> >> from the modules tree and commit: >> >> 927687809649 ("rust: macros: Add support for 'imports_ns' to module!") >> >> from the pwm tree. >> >> I followed a supplied resolution from Uwe and Danieli, thanks. Though I >> am just wondering (fromfollowing the pattern) if the "&ns" on line 545 >> should be "ns" - though I guess it would fail to build if so? We missed that non-trivial reference refactor. Sorry about it. In this case, ns is already a reference so, your guess is correct. It should be: @@ -348,6 +351,11 @@ pub(crate) fn module(ts: TokenStream) -> TokenStream { modinfo.emit("firmware", fw); } } + if let Some(imports) = &info.imports_ns { + for ns in imports { + modinfo.emit("import_ns", ns); + } + } This is when Andreas' patch is applied before Michal's. To be clear, here's what I mean: HEAD -> rust: macros: Add support for 'imports_ns' to module! rust: module: use a reference in macros::module::module >> >> I fixed it up (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/macros/module.rs >> index d62e9c1e2a89,408cd1154875..000000000000 >> --- a/rust/macros/module.rs >> +++ b/rust/macros/module.rs >> @@@ -205,50 -98,7 +205,51 @@@ struct ModuleInfo >> description: Option<String>, >> alias: Option<Vec<String>>, >> firmware: Option<Vec<String>>, >> + imports_ns: Option<Vec<String>>, >> + params: Option<Vec<Parameter>>, >> +} >> + >> +#[derive(Debug)] >> +struct Parameter { >> + name: String, >> + ptype: String, >> + default: String, >> + description: String, >> +} >> + >> +fn expect_params(it: &mut token_stream::IntoIter) -> Vec<Parameter> { >> + let params = expect_group(it); >> + assert_eq!(params.delimiter(), Delimiter::Brace); >> + let mut it = params.stream().into_iter(); >> + let mut parsed = Vec::new(); >> + >> + loop { >> + let param_name = match it.next() { >> + Some(TokenTree::Ident(ident)) => ident.to_string(), >> + Some(_) => panic!("Expected Ident or end"), >> + None => break, >> + }; >> + >> + assert_eq!(expect_punct(&mut it), ':'); >> + let param_type = expect_ident(&mut it); >> + let group = expect_group(&mut it); >> + assert_eq!(group.delimiter(), Delimiter::Brace); >> + assert_eq!(expect_punct(&mut it), ','); >> + >> + let mut param_it = group.stream().into_iter(); >> + let param_default = expect_param_default(&mut param_it); >> + let param_description = expect_string_field(&mut param_it, "description"); >> + expect_end(&mut param_it); >> + >> + parsed.push(Parameter { >> + name: param_name, >> + ptype: param_type, >> + default: param_default, >> + description: param_description, >> + }) >> + } >> + >> + parsed >> } >> >> impl ModuleInfo { >> @@@ -263,7 -113,7 +264,8 @@@ >> "license", >> "alias", >> "firmware", >> + "imports_ns", >> + "params", >> ]; >> const REQUIRED_KEYS: &[&str] = &["type", "name", "license"]; >> let mut seen_keys = Vec::new(); >> @@@ -289,7 -139,7 +291,8 @@@ >> "license" => info.license = expect_string_ascii(it), >> "alias" => info.alias = Some(expect_string_array(it)), >> "firmware" => info.firmware = Some(expect_string_array(it)), >> + "imports_ns" => info.imports_ns = Some(expect_string_array(it)), >> + "params" => info.params = Some(expect_params(it)), >> _ => panic!("Unknown key \"{key}\". Valid keys are: {EXPECTED_KEYS:?}."), >> } >> >> @@@ -329,25 -179,30 +332,30 @@@ pub(crate) fn module(ts: TokenStream) - >> // Rust does not allow hyphens in identifiers, use underscore instead. >> let ident = info.name.replace('-', "_"); >> let mut modinfo = ModInfoBuilder::new(ident.as_ref()); >> - if let Some(authors) = info.authors { >> + if let Some(authors) = &info.authors { >> for author in authors { >> - modinfo.emit("author", &author); >> + modinfo.emit("author", author); >> } >> } >> - if let Some(description) = info.description { >> - modinfo.emit("description", &description); >> + if let Some(description) = &info.description { >> + modinfo.emit("description", description); >> } >> modinfo.emit("license", &info.license); >> - if let Some(aliases) = info.alias { >> + if let Some(aliases) = &info.alias { >> for alias in aliases { >> - modinfo.emit("alias", &alias); >> + modinfo.emit("alias", alias); >> } >> } >> - if let Some(firmware) = info.firmware { >> + if let Some(firmware) = &info.firmware { >> for fw in firmware { >> - modinfo.emit("firmware", &fw); >> + modinfo.emit("firmware", fw); >> } >> } >> - if let Some(imports) = info.imports_ns { >> ++ if let Some(imports) = &info.imports_ns { >> + for ns in imports { >> + modinfo.emit("import_ns", &ns); Please, drop the '&' + modinfo.emit("import_ns", ns); >> + } >> + } >> >> // Built-in modules also export the `file` modinfo string. >> let file = > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: linux-next: manual merge of the pwm tree with the modules tree 2025-11-04 8:48 ` Daniel Gomez @ 2025-11-04 21:17 ` Stephen Rothwell 0 siblings, 0 replies; 9+ messages in thread From: Stephen Rothwell @ 2025-11-04 21:17 UTC (permalink / raw) To: Daniel Gomez Cc: Uwe Kleine-König, Luis Chamberlain, Daniel Gomez, Sami Tolvanen, Petr Pavlu, Andreas Hindborg, Linux Kernel Mailing List, Linux Next Mailing List, Michal Wilczynski [-- Attachment #1: Type: text/plain, Size: 450 bytes --] Hi Daniel, On Tue, 4 Nov 2025 09:48:35 +0100 Daniel Gomez <da.gomez@kernel•org> wrote: > > >> } > >> - if let Some(imports) = info.imports_ns { > >> ++ if let Some(imports) = &info.imports_ns { > >> + for ns in imports { > >> + modinfo.emit("import_ns", &ns); > > Please, drop the '&' > > + modinfo.emit("import_ns", ns); I will do that from today. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: linux-next: manual merge of the pwm tree with the modules tree 2025-11-03 23:54 ` Stephen Rothwell 2025-11-04 8:48 ` Daniel Gomez @ 2025-11-07 16:44 ` Uwe Kleine-König 2025-11-10 13:59 ` Daniel Gomez 1 sibling, 1 reply; 9+ messages in thread From: Uwe Kleine-König @ 2025-11-07 16:44 UTC (permalink / raw) To: Daniel Gomez Cc: Luis Chamberlain, Stephen Rothwell, Sami Tolvanen, Petr Pavlu, Andreas Hindborg, Daniel Gomez, Linux Kernel Mailing List, Linux Next Mailing List, Michal Wilczynski [-- Attachment #1: Type: text/plain, Size: 2010 bytes --] Hi Daniel, On Tue, Nov 04, 2025 at 10:54:15AM +1100, Stephen Rothwell wrote: > [adding the modules tree contacts] > > On Tue, 4 Nov 2025 10:48:27 +1100 Stephen Rothwell <sfr@canb•auug.org.au> wrote: > > > > Today's linux-next merge of the pwm tree got a conflict in: > > > > rust/macros/module.rs > > > > between commits: > > > > 3809d7a89fe5 ("rust: module: use a reference in macros::module::module") > > 0b24f9740f26 ("rust: module: update the module macro with module parameter support") > > > > from the modules tree and commit: > > > > 927687809649 ("rust: macros: Add support for 'imports_ns' to module!") I reshuffled my tree such that the import_ns commit sits directly on top of 6.18-rc1. The new commit-id is 739ad9be61e5. > > from the pwm tree. > > [...] > > - if let Some(imports) = info.imports_ns { > > ++ if let Some(imports) = &info.imports_ns { > > + for ns in imports { > > + modinfo.emit("import_ns", &ns); > > + } > > + } Given that the conflict resolution is non-trivial and we already know what to do, I suggest you merge my commit into the modules tree. I created a signed tag for that: The following changes since commit 3a8660878839faadb4f1a6dd72c3179c1df56787: Linux 6.18-rc1 (2025-10-12 13:42:36 -0700) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux.git tags/rust-module-namespace for you to fetch changes up to 739ad9be61e5f53dbd8d7d7e80723d0799ff077c: rust: macros: Add support for 'imports_ns' to module! (2025-11-07 10:01:53 +0100) ---------------------------------------------------------------- immutable branch containing module namespace support for Rust ---------------------------------------------------------------- Michal Wilczynski (1): rust: macros: Add support for 'imports_ns' to module! rust/macros/module.rs | 8 ++++++++ 1 file changed, 8 insertions(+) Thanks Uwe [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: linux-next: manual merge of the pwm tree with the modules tree 2025-11-07 16:44 ` Uwe Kleine-König @ 2025-11-10 13:59 ` Daniel Gomez 2025-11-10 15:42 ` Uwe Kleine-König 0 siblings, 1 reply; 9+ messages in thread From: Daniel Gomez @ 2025-11-10 13:59 UTC (permalink / raw) To: Uwe Kleine-König, Daniel Gomez Cc: Luis Chamberlain, Stephen Rothwell, Sami Tolvanen, Petr Pavlu, Andreas Hindborg, Linux Kernel Mailing List, Linux Next Mailing List, Michal Wilczynski On 07/11/2025 17.44, Uwe Kleine-König wrote: > Hi Daniel, > > On Tue, Nov 04, 2025 at 10:54:15AM +1100, Stephen Rothwell wrote: >> [adding the modules tree contacts] >> >> On Tue, 4 Nov 2025 10:48:27 +1100 Stephen Rothwell <sfr@canb•auug.org.au> wrote: >>> >>> Today's linux-next merge of the pwm tree got a conflict in: >>> >>> rust/macros/module.rs >>> >>> between commits: >>> >>> 3809d7a89fe5 ("rust: module: use a reference in macros::module::module") >>> 0b24f9740f26 ("rust: module: update the module macro with module parameter support") >>> >>> from the modules tree and commit: >>> >>> 927687809649 ("rust: macros: Add support for 'imports_ns' to module!") > > I reshuffled my tree such that the import_ns commit sits directly on top > of 6.18-rc1. The new commit-id is 739ad9be61e5. > >>> from the pwm tree. >>> [...] >>> - if let Some(imports) = info.imports_ns { >>> ++ if let Some(imports) = &info.imports_ns { >>> + for ns in imports { >>> + modinfo.emit("import_ns", &ns); >>> + } >>> + } > > Given that the conflict resolution is non-trivial and we already know > what to do, I suggest you merge my commit into the modules tree. Do you mean creating a separate branch that includes the conflict resolution, to be used as an example when sending the PR? ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: linux-next: manual merge of the pwm tree with the modules tree 2025-11-10 13:59 ` Daniel Gomez @ 2025-11-10 15:42 ` Uwe Kleine-König 2025-11-10 15:54 ` Daniel Gomez 0 siblings, 1 reply; 9+ messages in thread From: Uwe Kleine-König @ 2025-11-10 15:42 UTC (permalink / raw) To: Daniel Gomez Cc: Daniel Gomez, Luis Chamberlain, Stephen Rothwell, Sami Tolvanen, Petr Pavlu, Andreas Hindborg, Linux Kernel Mailing List, Linux Next Mailing List, Michal Wilczynski [-- Attachment #1: Type: text/plain, Size: 1802 bytes --] Hello Daniel, On Mon, Nov 10, 2025 at 02:59:15PM +0100, Daniel Gomez wrote: > On 07/11/2025 17.44, Uwe Kleine-König wrote: > > Hi Daniel, > > > > On Tue, Nov 04, 2025 at 10:54:15AM +1100, Stephen Rothwell wrote: > >> [adding the modules tree contacts] > >> > >> On Tue, 4 Nov 2025 10:48:27 +1100 Stephen Rothwell <sfr@canb•auug.org.au> wrote: > >>> > >>> Today's linux-next merge of the pwm tree got a conflict in: > >>> > >>> rust/macros/module.rs > >>> > >>> between commits: > >>> > >>> 3809d7a89fe5 ("rust: module: use a reference in macros::module::module") > >>> 0b24f9740f26 ("rust: module: update the module macro with module parameter support") > >>> > >>> from the modules tree and commit: > >>> > >>> 927687809649 ("rust: macros: Add support for 'imports_ns' to module!") > > > > I reshuffled my tree such that the import_ns commit sits directly on top > > of 6.18-rc1. The new commit-id is 739ad9be61e5. > > > >>> from the pwm tree. > >>> [...] > >>> - if let Some(imports) = info.imports_ns { > >>> ++ if let Some(imports) = &info.imports_ns { > >>> + for ns in imports { > >>> + modinfo.emit("import_ns", &ns); > >>> + } > >>> + } > > > > Given that the conflict resolution is non-trivial and we already know > > what to do, I suggest you merge my commit into the modules tree. > > Do you mean creating a separate branch that includes the conflict resolution, to > be used as an example when sending the PR? If I were the module maintainer I'd pull https://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux.git rust-module-namespace into my tree and include that into the v6.19-rc1 pull request. That way the merge conflict doesn't happen at all for Linus. Best regards Uwe [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: linux-next: manual merge of the pwm tree with the modules tree 2025-11-10 15:42 ` Uwe Kleine-König @ 2025-11-10 15:54 ` Daniel Gomez 2025-11-10 18:32 ` Uwe Kleine-König 0 siblings, 1 reply; 9+ messages in thread From: Daniel Gomez @ 2025-11-10 15:54 UTC (permalink / raw) To: Uwe Kleine-König Cc: Daniel Gomez, Luis Chamberlain, Stephen Rothwell, Sami Tolvanen, Petr Pavlu, Andreas Hindborg, Linux Kernel Mailing List, Linux Next Mailing List, Michal Wilczynski On 10/11/2025 16.42, Uwe Kleine-König wrote: > Hello Daniel, > > On Mon, Nov 10, 2025 at 02:59:15PM +0100, Daniel Gomez wrote: >> On 07/11/2025 17.44, Uwe Kleine-König wrote: >>> Hi Daniel, >>> >>> On Tue, Nov 04, 2025 at 10:54:15AM +1100, Stephen Rothwell wrote: >>>> [adding the modules tree contacts] >>>> >>>> On Tue, 4 Nov 2025 10:48:27 +1100 Stephen Rothwell <sfr@canb•auug.org.au> wrote: >>>>> >>>>> Today's linux-next merge of the pwm tree got a conflict in: >>>>> >>>>> rust/macros/module.rs >>>>> >>>>> between commits: >>>>> >>>>> 3809d7a89fe5 ("rust: module: use a reference in macros::module::module") >>>>> 0b24f9740f26 ("rust: module: update the module macro with module parameter support") >>>>> >>>>> from the modules tree and commit: >>>>> >>>>> 927687809649 ("rust: macros: Add support for 'imports_ns' to module!") >>> >>> I reshuffled my tree such that the import_ns commit sits directly on top >>> of 6.18-rc1. The new commit-id is 739ad9be61e5. >>> >>>>> from the pwm tree. >>>>> [...] >>>>> - if let Some(imports) = info.imports_ns { >>>>> ++ if let Some(imports) = &info.imports_ns { >>>>> + for ns in imports { >>>>> + modinfo.emit("import_ns", &ns); >>>>> + } >>>>> + } >>> >>> Given that the conflict resolution is non-trivial and we already know >>> what to do, I suggest you merge my commit into the modules tree. >> >> Do you mean creating a separate branch that includes the conflict resolution, to >> be used as an example when sending the PR? > > If I were the module maintainer I'd pull > > https://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux.git rust-module-namespace > > into my tree and include that into the v6.19-rc1 pull request. That way > the merge conflict doesn't happen at all for Linus. That's not my understanding on how to deal with conflicts: https://docs.kernel.org/maintainer/rebasing-and-merging.html#merging-from-sibling-or-upstream-trees > > Best regards > Uwe ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: linux-next: manual merge of the pwm tree with the modules tree 2025-11-10 15:54 ` Daniel Gomez @ 2025-11-10 18:32 ` Uwe Kleine-König 0 siblings, 0 replies; 9+ messages in thread From: Uwe Kleine-König @ 2025-11-10 18:32 UTC (permalink / raw) To: Daniel Gomez Cc: Daniel Gomez, Luis Chamberlain, Stephen Rothwell, Sami Tolvanen, Petr Pavlu, Andreas Hindborg, Linux Kernel Mailing List, Linux Next Mailing List, Michal Wilczynski [-- Attachment #1: Type: text/plain, Size: 2061 bytes --] Hello Daniel, On Mon, Nov 10, 2025 at 04:54:01PM +0100, Daniel Gomez wrote: > On 10/11/2025 16.42, Uwe Kleine-König wrote: > > On Mon, Nov 10, 2025 at 02:59:15PM +0100, Daniel Gomez wrote: > >> On 07/11/2025 17.44, Uwe Kleine-König wrote: > >>> Given that the conflict resolution is non-trivial and we already know > >>> what to do, I suggest you merge my commit into the modules tree. > >> > >> Do you mean creating a separate branch that includes the conflict resolution, to > >> be used as an example when sending the PR? > > > > If I were the module maintainer I'd pull > > > > https://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux.git rust-module-namespace > > > > into my tree and include that into the v6.19-rc1 pull request. That way > > the merge conflict doesn't happen at all for Linus. > > > That's not my understanding on how to deal with conflicts: > > https://docs.kernel.org/maintainer/rebasing-and-merging.html#merging-from-sibling-or-upstream-trees Note the "don't" described in the docs isn't what I suggested to do here. The rust-module-namespace is a change that belongs into the modules tree and that I build upon in my tree. So this is (somewhat) the case "Another reason for doing merges of upstream or another subsystem tree is to resolve dependencies". Only the merge direction is wrong because the usual expectation is that a change to rust/macros/module.rs originates in the modules (or some rust) tree. But for the justification and also the resulting commit topology that doesn't matter. Also "[back merges] will significantly increase your chances of encountering bugs from elsewhere in the community and make it hard to ensure that the work you are managing is stable and ready for upstream." doesn't apply because by merging the suggested tag you only get a single commit and not my complete pwm tree. If you want to convince yourself this is in fact quite usual I suggest looking at https://lore.kernel.org/all/?q=s%3APULL+AND+s%3AImmutable. Best regards Uwe [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2025-11-10 18:32 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2025-11-03 23:48 linux-next: manual merge of the pwm tree with the modules tree Stephen Rothwell 2025-11-03 23:54 ` Stephen Rothwell 2025-11-04 8:48 ` Daniel Gomez 2025-11-04 21:17 ` Stephen Rothwell 2025-11-07 16:44 ` Uwe Kleine-König 2025-11-10 13:59 ` Daniel Gomez 2025-11-10 15:42 ` Uwe Kleine-König 2025-11-10 15:54 ` Daniel Gomez 2025-11-10 18:32 ` Uwe Kleine-König
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox