4 ms·

Thanks for posting this to HN! Author here, happy to answer any questions. (By the way, I did not originally start the project, though I've worked quite a bit

Thanks for posting this to HN! Author here, happy to answer any questions. (By the way, I did not originally start the project, though I've worked quite a bit on the safe abstractions that are mentioned in the roadmap).

ndesaulniers 2y ago
Bullish or bearish on rust in the kernel?
- bonzini 2y ago
  Hello! Small world. :) For drivers, it's already happening, especially for graphics but not limited to that. 6.13 has some very important changes. A lot of Linux is drivers so that's already a reason to be bullish. Answering for QEMU instead: it depends on the community being willing to share the burden of writing the FFI code. Despite Rust being low level, there is still a substantial amount of work to do. Replies to the roadmap pointed out tracepoints as an area where I know nothing and therefore I would like someone else to do the work (I am working mostly on the object and threading models, which is also where a lot of the impedance mismatch between Rust and C lies).
  - aapoalas 2y ago
    Hello. I assume tracepoints mean kprobes/uprobes or something along those lines? I've just this weekend worked on implementing/adapting a crate for DTrace USDTs aka DTrace probes to also work on Linux and generate SystemTap SDTs (aka USDTs aka dtrace probes). This is probably a little different from tracepoints in the kernel space but I'm somewhat interested in going deeper and into the kernel side of things. Let me know if you have any pointers as to where I might be of concrete assistance to you!
    - bonzini 2y ago
      QEMU has several tracepoint providers, the main ones are (a slightly fancy version of) printf and USDT. There is a Python program that generates the C code for the chosen backend(s), so the thing to do would be to adjust the script to produce either an FFI bridge or the equivalent Rust code.
      - aapoalas 2y ago
        Can you link the script? This sounds vaguely like something that would be no skin off my back, so I'd be quite happy to help with this.
        bonzini 2y ago
        Yes it's https://github.com/qemu/qemu/tree/master/scripts/tracetool https://github.com/qemu/qemu/tree/master/scripts/tracetool. I also found https://github.com/cuviper/probe-rs/tree/master/src/platform https://github.com/cuviper/probe-rs/tree/master/src/platform which seems interesting.
        aapoalas 2y ago
        Here's my WIP addition to Oxide Computer's usdt crate: https://github.com/oxidecomputer/usdt/pull/340 https://github.com/oxidecomputer/usdt/pull/340 This crate gives you a nifty macro that translates Rust probe definitions into the correct ELF sections and other related assembly. Other ways to declare probes are also supported, though. Their support is currently only for illumos and OS X but I managed to get Linux SystemTap SDTs working as well, and a PR for FreeBSD exists as well but has been languishing in review purgatory for two years: I imagine QEMU might enjoy this wide support (if they land).
JoshTriplett 2y ago
What does your wishlist for Rust look like? (Besides "simpler C/Rust interoperability", of course.) Has QEMU run into things that Rust-for-Linux hasn't, that feel missing from the Rust language?
- bonzini 2y ago
  Right now the only language-level thing I would like is const operator overloading. Even supporting MSRV as old as 1.63 was not a big deal, the worst thing was dependencies using let...else which we will vendor and patch. Pin is what it is, but it is mostly okay since I haven't needed projection so far. Initialization using Linux's "impl PinInit<Self>" approach seems to be working very well in my early experiments, I contributed changes to use the crate without unstable features. In the FFI area: Bindgen support for toml configuration (https://github.com/rust-lang/rust-bindgen/pull/2917 https://github.com/rust-lang/rust-bindgen/pull/2917 but it could also be response files on the command line), and easier passing of closures from Rust to C (though I found a very nice way to do it for ZSTs that implement Fn, which is by far the common case). The "data structure interoperability" part of the roadmap is something I should present to someone in the Rust community for impressions. Some kind of standardization of core FFI traits would be nice. Outside the Rust core proper, Meson support needs to mature a bit for ease of use, but it is getting there. Linux obviously doesn't need that. BTW, saw your comment in the dead thread, you're too nice. I have been curious about Rust for some time and with Linux maturing, and Linaro doing the first contribution of build system integration + sample device code, it was time to give it a try.
  - JoshTriplett 2y ago
    > Right now the only language-level thing I would like is const operator overloading. As far as I know, const traits are still on track. > easier passing of closures from Rust to C As in, turning a Rust closure into a C function-pointer-plus-context-parameter? > The "data structure interoperability" part of the roadmap is something I should present to someone in the Rust community for impressions. Some kind of standardization of core FFI traits would be nice. Would be happy to work with you to get something on the calendar.
o11c 2y ago
> Related to this, the IsA trait allows typesafe compile-time checked casts. Unlike in C code, casting to a superclass can be written in such a way that the compiler will complain if the destination type is not a superclass, and with zero runtime cost. This is unfair to C. With a little work when defining all classes (or non-leaf classes if you're willing for a hairier implementation), you can do this there too. There are probably other ways, but the way that seems most "obvious" to me is to define the base via union of all bases in the chain, rather than only the immediate base class. So: /* class Foo {int f;}; class Bar extends Foo {int b;}; class Qux extends Bar {int q;}; class Leaf extends Qux {int l;}; */ struct Foo { int f; }; struct Bar { union { struct Foo base, base_Foo}; int b; }; struct Qux { union { struct Bar base, base_Bar; struct Foo base_Foo; }; int q; }; struct Leaf { struct Qux base; int l; } Then your "compile-time-safe-cast to base class" macro just checks 3 things in order: 1. check if we're already the right class. 2. check if `base` is the right class. 3. unconditionally try to use the appropriately-named `base_Foo` member as calculated from the type. (runtime-safe-checked downcasts just have to check that the reverse is possible)
- bonzini 2y ago
  "Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should." :D Though I admit that Rust also has to include the full list of base classes (https://github.com/rust-lang/rfcs/pull/1268 https://github.com/rust-lang/rfcs/pull/1268 would fix it).
  - o11c 2y ago
    The main reason the C version must hard-code is because C macros can't be recursive. What's Rust's excuse? (that said, the C approach is also nice for manually accessing fields of distant base classes)
    - bonzini 2y ago
      In Rust's case it is that when you say "you have IsA<Device> for all types that implement IsA<PCIDevice>" you are actually saying "you have IsA<Device> for all types, but only if they implement IsA<PCIDevice>". When you later say "you have IsA<Device> for all types, but only if they implement IsA<I2CDevice>" the two conditions conflict. It might be possible to avoid this issue with a different implementation but this is the simplest one that works and QEMU's hierarchy is generally shallow. If a better implementation came along, it would be a matter of search and repeat.

ndesaulniers 2y ago

Bullish or bearish on rust in the kernel?

bonzini 2y ago
Hello! Small world. :) For drivers, it's already happening, especially for graphics but not limited to that. 6.13 has some very important changes. A lot of Linux is drivers so that's already a reason to be bullish. Answering for QEMU instead: it depends on the community being willing to share the burden of writing the FFI code. Despite Rust being low level, there is still a substantial amount of work to do. Replies to the roadmap pointed out tracepoints as an area where I know nothing and therefore I would like someone else to do the work (I am working mostly on the object and threading models, which is also where a lot of the impedance mismatch between Rust and C lies).
- aapoalas 2y ago
  Hello. I assume tracepoints mean kprobes/uprobes or something along those lines? I've just this weekend worked on implementing/adapting a crate for DTrace USDTs aka DTrace probes to also work on Linux and generate SystemTap SDTs (aka USDTs aka dtrace probes). This is probably a little different from tracepoints in the kernel space but I'm somewhat interested in going deeper and into the kernel side of things. Let me know if you have any pointers as to where I might be of concrete assistance to you!
  - bonzini 2y ago
    QEMU has several tracepoint providers, the main ones are (a slightly fancy version of) printf and USDT. There is a Python program that generates the C code for the chosen backend(s), so the thing to do would be to adjust the script to produce either an FFI bridge or the equivalent Rust code.
    - aapoalas 2y ago
      Can you link the script? This sounds vaguely like something that would be no skin off my back, so I'd be quite happy to help with this.
      - bonzini 2y ago
        Yes it's https://github.com/qemu/qemu/tree/master/scripts/tracetool https://github.com/qemu/qemu/tree/master/scripts/tracetool. I also found https://github.com/cuviper/probe-rs/tree/master/src/platform https://github.com/cuviper/probe-rs/tree/master/src/platform which seems interesting.
        aapoalas 2y ago
        Here's my WIP addition to Oxide Computer's usdt crate: https://github.com/oxidecomputer/usdt/pull/340 https://github.com/oxidecomputer/usdt/pull/340 This crate gives you a nifty macro that translates Rust probe definitions into the correct ELF sections and other related assembly. Other ways to declare probes are also supported, though. Their support is currently only for illumos and OS X but I managed to get Linux SystemTap SDTs working as well, and a PR for FreeBSD exists as well but has been languishing in review purgatory for two years: I imagine QEMU might enjoy this wide support (if they land).

JoshTriplett 2y ago

What does your wishlist for Rust look like? (Besides "simpler C/Rust interoperability", of course.) Has QEMU run into things that Rust-for-Linux hasn't, that feel missing from the Rust language?

bonzini 2y ago
Right now the only language-level thing I would like is const operator overloading. Even supporting MSRV as old as 1.63 was not a big deal, the worst thing was dependencies using let...else which we will vendor and patch. Pin is what it is, but it is mostly okay since I haven't needed projection so far. Initialization using Linux's "impl PinInit<Self>" approach seems to be working very well in my early experiments, I contributed changes to use the crate without unstable features. In the FFI area: Bindgen support for toml configuration (https://github.com/rust-lang/rust-bindgen/pull/2917 https://github.com/rust-lang/rust-bindgen/pull/2917 but it could also be response files on the command line), and easier passing of closures from Rust to C (though I found a very nice way to do it for ZSTs that implement Fn, which is by far the common case). The "data structure interoperability" part of the roadmap is something I should present to someone in the Rust community for impressions. Some kind of standardization of core FFI traits would be nice. Outside the Rust core proper, Meson support needs to mature a bit for ease of use, but it is getting there. Linux obviously doesn't need that. BTW, saw your comment in the dead thread, you're too nice. I have been curious about Rust for some time and with Linux maturing, and Linaro doing the first contribution of build system integration + sample device code, it was time to give it a try.
- JoshTriplett 2y ago
  > Right now the only language-level thing I would like is const operator overloading. As far as I know, const traits are still on track. > easier passing of closures from Rust to C As in, turning a Rust closure into a C function-pointer-plus-context-parameter? > The "data structure interoperability" part of the roadmap is something I should present to someone in the Rust community for impressions. Some kind of standardization of core FFI traits would be nice. Would be happy to work with you to get something on the calendar.

o11c 2y ago

> Related to this, the IsA trait allows typesafe compile-time checked casts. Unlike in C code, casting to a superclass can be written in such a way that the compiler will complain if the destination type is not a superclass, and with zero runtime cost. This is unfair to C. With a little work when defining all classes (or non-leaf classes if you're willing for a hairier implementation), you can do this there too. There are probably other ways, but the way that seems most "obvious" to me is to define the base via union of all bases in the chain, rather than only the immediate base class. So: /* class Foo {int f;}; class Bar extends Foo {int b;}; class Qux extends Bar {int q;}; class Leaf extends Qux {int l;}; */ struct Foo { int f; }; struct Bar { union { struct Foo base, base_Foo}; int b; }; struct Qux { union { struct Bar base, base_Bar; struct Foo base_Foo; }; int q; }; struct Leaf { struct Qux base; int l; } Then your "compile-time-safe-cast to base class" macro just checks 3 things in order: 1. check if we're already the right class. 2. check if `base` is the right class. 3. unconditionally try to use the appropriately-named `base_Foo` member as calculated from the type. (runtime-safe-checked downcasts just have to check that the reverse is possible)

bonzini 2y ago
"Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should." :D Though I admit that Rust also has to include the full list of base classes (https://github.com/rust-lang/rfcs/pull/1268 https://github.com/rust-lang/rfcs/pull/1268 would fix it).
- o11c 2y ago
  The main reason the C version must hard-code is because C macros can't be recursive. What's Rust's excuse? (that said, the C approach is also nice for manually accessing fields of distant base classes)
  - bonzini 2y ago
    In Rust's case it is that when you say "you have IsA<Device> for all types that implement IsA<PCIDevice>" you are actually saying "you have IsA<Device> for all types, but only if they implement IsA<PCIDevice>". When you later say "you have IsA<Device> for all types, but only if they implement IsA<I2CDevice>" the two conditions conflict. It might be possible to avoid this issue with a different implementation but this is the simplest one that works and QEMU's hierarchy is generally shallow. If a better implementation came along, it would be a matter of search and repeat.