Re: [PATCH] rust: Fix build error

[Eder Zulian <ezulian@redhat.com>]

Hi Miguel,
On Mon, Oct 14, 2024 at 10:38:45PM +0200, Miguel Ojeda wrote:
> On Mon, Oct 14, 2024 at 9:54 PM Eder Zulian <ezulian@redhat.com> wrote:
> >
> > Error observed while building a rt-debug kernel for aarch64.
> 
> Thanks for testing with Rust enabled!
Sure, it's been fun!
> 
> > Suggested-by: Clark Williams <williams@redhat.com>
> 
> Do you mean `Reported-by`?
Yes, my mistake.
> 
> Also, I am not sure which `Fixes:` tag would fit best here, since
> `PREEMPT_RT` has been around for quite a while, but only enabled very
> recently. Thomas: do you have a preference?
> 
I can try to find a culprit and add a 'Fixes:' tag. In my opnion, at first
glance, it would be the patch that introduced the Rust helper for spinlocks.
Not sure.
> In addition (sorry, it was in my backlog):
> 
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202409251238.vetlgXE9-lkp@intel.com/
> 
I can fix it and send a v2 if that's ok. Is it valid to add two 'Reported-by'
tags (Clark and kernel test robot)?
> Finally, I think we should perhaps put a helper in `spinlock{_,rt}.h`
> that takes the `key` (instead of having this `#ifdef` here) and then
> just use that from the Rust helpers, because we don't want to
> duplicate such logic (conditionals) in helpers. And with the RT init
Agreed. We don't want code replicated. In my reply to Boqun I added some
notes. If that makes sense, we could avoid even the helper in
'spinlock{_,rt}.h'?
> open coding that Boqun mentioned, even more. After all, helpers are
> meant to be as straightforward as possible, and if we have this sort
> of thing in helpers, it is harder for everyone to keep them in sync.
Please correct me if I misunderstood. It seems that Rust doesn't have a
pre-processor step to replace macros in the code and the Rust compiler works
with 'objects/entities' created for functions and variables, but macros would
be ignored (since they are string substitution.) Do you have pointers for good
docs on this?
> 
> In other words, I see helpers as following the same "avoid `#ifdef`s"
> rule that we prefer in C source files vs. headers.
> 
> What do you think, Thomas?
> 
> >
> 
> Spurious newline.
Thanks, I'll fix the spurious new line.
> 
Thank you.
> Cheers,
> Miguel
>