Re: [TECH TOPIC] Rust for Linux

Miguel Ojeda
2021-07-20T12:11:01Z

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