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).
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!
I also found https://github.com/cuviper/probe-rs/tree/master/src/platform which seems interesting.
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).
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 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.
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.
Yes they are. My use case is something like the bitflags crate, there are lots of bit flags in emulated devices of course. In the meanwhile I guess it would be possible to use macros to turn something like "bit_const!(Type:A|B)" to "Type(A.0|B.0)" or something like that.
> As in, turning a Rust closure into a C function-pointer-plus-context-parameter?
Yes, more in general everything related to callbacks is doable but very verbose. We might do (procedural?) macro magic later on to avoid the verbosity but for now I prefer to stick to pure Rust until there's an idea of which patterns recur.
Let me know by email about any occasions to present what I have.
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; }
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.
Though I admit that Rust also has to include the full list of base classes (https://github.com/rust-lang/rfcs/pull/1268 would fix it).
(that said, the C approach is also nice for manually accessing fields of distant base classes)
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.
Can you please show a concrete example? Thanks.
Will it work on most tool chains? Yes. But when it doesn't, it is going to be fun.
This one I wasn't familiar with, and I believe it absolves the comment I initially replied to in this thread.
> 6.5.2.3.6 states:
> One special guarantee is made in order to simplify the use of unions: if a union contains several structures that share a common initial sequence (see below), and if the union object currently contains one of these structures, it is permitted to inspect the common initial part of any of them anywhere that a declaration of the completed type of the union is visible
Outside of that special case, the general semantics of unions are specified as follows. I think that means you are right?
> 6.2.6.1.7 states
> When a value is stored in a member of an object of union type, the bytes of the object representation that do not correspond to that member but do correspond to other members take unspecified values
99) If the member used to read the contents of a union object is not the same as the member last used to store a value in the object, the appropriate part of the object representation of the value is reinterpreted as an object representation in the new type as described in 6.2.6 (a process sometimes called "type punning"). This might be a trap representation.
...it all makes sense until that last sentence, maybe that's for really weird bit casts like trying to reinterpret an integer as float. FWIW the only place I used union type punning was in an Z80 emulator for the 16-bit register pairs, but that's no longer necessary, since modern compilers will optimize two consequitive byte reads into a single word read:
(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).