On Wed, Nov 29, 2023 at 04:23:05PM +0100, Peter Zijlstra wrote:
> On Wed, Nov 29, 2023 at 03:13:22PM +0000, Matthew Wilcox wrote:
>
> > > @@ -157,6 +158,12 @@ void rust_helper_init_work_with_key(struct work_struct *work, work_func_t func,
> > > }
> > > EXPORT_SYMBOL_GPL(rust_helper_init_work_with_key);
> > >
> > > +struct file *rust_helper_get_file(struct file *f)
> > > +{
> > > + return get_file(f);
> > > +}
> > > +EXPORT_SYMBOL_GPL(rust_helper_get_file);
> >
> > This is ridiculous. A function call instead of doing the
> > atomic_long_inc() in Rust?
>
> Yeah, I complained about something similar a while ago. And recently
> talked to Boqun about this as well,
>
> Bindgen *could* in theory 'compile' the inline C headers into (unsafe)
> Rust, the immediate problem is that Rust has a wildly different inline
> asm syntax (because Rust needs terrible syntax or whatever).
>
> Boqun said it should all be fixable, but is a non-trivial amount of
> work.
>
Right, but TBH, I was only thinking about "inlining" our atomic
primitives back then. The idea is since atomic primitives only have
small body (most of which is asm code), it's relatively easy to
translate that from a C function into a Rust one. And what's left is
translating asm blocks. Things get interesting here:
Originally I think the translation, despite the different syntax, might
be relatively easy, for example, considering smp_store_release() on
ARM64, we are going to translate from
asm volatile ("stlr %w1, %0" \
: "=Q" (*__p) \
: "rZ" (*(__u32 *)__u.__c) \
: "memory");
to something like:
asm!("stlr {val}, [{ptr}]",
val = in(reg) __u.__c,
ptr = in(reg) __p);
, the translation is non-trivial, but it's not that hard, since it's
basically find-and-replace.
But but but, I then realized we have asm goto in C but Rust doesn't
support them, and I haven't thought through how hard tht would be..
Regards,
Boqun
