Re: [PATCH] rust: Fix build error

[Eder Zulian <ezulian@redhat.com>]

Hi,
Really sorry for the long pause, I was OOO for some days...

On Thu, Oct 17, 2024 at 03:24:06PM +0200, Miguel Ojeda wrote:
> On Thu, Oct 17, 2024 at 2:15 AM Eder Zulian <ezulian@redhat.com> wrote:
> >
> > 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)?
> 
> Yeah, I think so, at least if they were independently reported. Please
> add a `Closes` if you have it for Clark's report.
> 
> > 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'?
> 
> Hmm... I am not sure I follow your reply to Boqun. In your version,
> under `DEBUG_SPINLOCK && PREEMPT_RT`, you call `spin_lock_init`, but
> that means we are not passing the given key but creating a new
> static/single one, no? That is why Boqun mentioned that.
> 

I shall send v2 based on Boqun's suggestion soon.

> > 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?
> 
> I am not sure what exactly you are referring to, so perhaps this quick
> summary helps (apologies if you already know all this!).
> 
> Rust does not understand C, at all. So we use `bindgen`, which is a
> tool that internally uses `libclang` to parse C headers and emit Rust
> code to use them from Rust. Clang (of course) knows about macros and
> can parse them and expand them etc., but those macros (typically)
> expand into C code, not Rust code. So (typically) we can't simply use
> the macro because it does not generate valid Rust code. Thus we use a
> C source file to declare helpers that call the C macros (which is fine
> because it is a C file compiled by a C compiler), and then we can call
> the C helper function from Rust.
> 
> The problem Boqun pointed out is that, now, since you introduced an
> extra condition in the same `#ifdef`, then `spin_lock_init` is also
> called in a case when `DEBUG_SPINLOCK=y`, which means the key that was
> passed as a parameter is not used but the macro will provide a new
> one.
> 
> Does that help?

Yes, thank you!

> 
> As for docs, I am happy to point to some -- do you mean on the Rust
> side of things?
> 
> Thanks for the patch!
> 
> Cheers,
> Miguel
> 

Cheeers,
Eder