Re: [TECH TOPIC] Rust for Linux

[Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>]

On Tue, Jul 20, 2021 at 11:39 AM Alexandre Belloni
<alexandre.belloni@bootlin.com> wrote:
>
> Well, the point is exactly to have a look at that extra work.

That is fine, but you did not say so :) I interpreted you wanted to
compare the codegen quality, rather than take a look at the extra
features.

> I was under the impression that you would compile the kernel with
> overflow checks enabled, why would you disable them here?

Please see the previous point: it is not that useful to compare object
files that do different things (if checking codegen quality), thus I
removed some of the differences, including the overflow checks.

The extra work can be done in both C and Rust (or in neither), so it
is not related to the language choice.

> But do we care about very simple test cases? The pl061 driver is already
> simple and this would be an example of what to expect for most of the
> simple drivers that would get converted.

Ditto.

> This is a function call, I would not call that closer to the C

I explained this in the beginning of the message: `bindgen` cannot
convert C macros, thus we use a helper function, and since
cross-language LTO is not yet supported, LLVM cannot inline the call.

Of course, we could do inline assembly in the Rust side too, but I
would say it is best to work on cross-language LTO and see if that is
good enough before duplicating code.

We could also do it here for demonstration purposes, if you want.

> version. Can we see rust_helper_readb?

Of course:

    00000000000004d8 <rust_helper_readb>:
        4d8:    39400000    ldrb    w0, [x0]
        4dc:    d50331bf    dmb     oshld
        4e0:    92401c08    and     x8, x0, #0xff
        4e4:    ca080108    eor     x8, x8, x8
        4e8:    b5000008    cbnz    x8, 4e8 <rust_helper_readb+0x10>
        4ec:    d65f03c0    ret

As you can see, it is just the inline assembly generated by the arm64
arch macros.

Cheers,
Miguel