Hi everyone,
The idea of having some Rust interop for libtraceevent was floated during the
Tracing Summit that took place this week.
The overall work has two scopes:
1. libtraceevent: low-level helpers to decode event formats and binary buffer pages.
2. high level API that e.g. can consume a trace.dat file and expose an iterator API etc.
The current discussion is only about #1. The 2nd part of the work has an
entirely different set of constraints as it would aim at integrating in the
Rust ecosystem as well as possible without trying to replace anything
pre-existent.
* Rust bindings for C code:
Pros:
* Faster to implement
* By construction, any current covered use case stays covered.
Cons:
* Less straightforward to build and distribute on crates.io. Current
best practice seems to simply expect the C lib to already be
compiled/installed on the host system and find it with pkg-config.
Otherwise, the lib sources can be bundled and a build recipe
included. At any rate, it will bring back the daemons of C package
management world where Rust typically only requires "cargo build" to
obtain a working binary.
* More unsafe code overall when combined with higher level Rust code.
* Rust implementation:
Pros:
* Occasion to fix unsatisfactory points in the current API:
* Some inefficiencies due to looking up fields by name mentioned
by Steven (correct that if I did not get it right).
* Some unsatisfactory naming convention (Steven).
* Event format is hard to parse as lots of event strongly
depends on the format string to specify the actual type. E.g. The
print event uses unsigned long for "ip" and then casts to (void*)
in the format string. sched_switch or mm_page_alloc require even
more advanced C parsing power to extract info necessary to
correctly/usefully represent the state type in most languages.
This might be fixable with more codified best practices and
fixing existing trace events, but we would still need to deal
with the existing situation for a few more years at best. A new
API could merge the type info from the parsed print format with
the other "ABI info" to expose a richer representation to
consumers.
* Can be used by higher level Rust code, preserving soundness
guarantees end to end.
* Can open new use cases such as:
* Likely easier to maintain Python bindings using e.g. PyO3
* Good WASM support is something the Rust community cares about, so
that might open an avenue for new trace visualization tools.
Cons:
* More work than just making bindings for existing C code.
* Portability: is there any architecture not currenlty supported by
Rust we care about ?
* New toolchain required to build the code. rustup solves that issue
very well though.
Possible cons requiring a prototype to check:
* If we aim at 100% API/ABI compatibility with current libtraceevent,
this may force Rust code into very non-idiomatic code that may affect
the benefits of the language.
* While it can still be exposed to C code, some soundness
guarantees will likely be lost in passing: Rust ref to C pointer
conversion is statically lossy. Having a func implemented in Rust
does not magically make consuming C compilers smarter and able to
check for memory safety. The improvement would only be inside the
implementation itself, but if we expose relatively simple low level
helpers the advantage is decreased.
I'm sure I missed some things, so let's use this thread to get a better view of
where to head next.
Steven also made a twitter poll on the matter:
https://twitter.com/srostedt/status/1580589911706521600
Thanks,
Douglas
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
|