Rust Integration

[hoeppnerj]

Hi everyone,

there is now a separate branch that showcases the integration of Rust written tools into the currently used Makefile based buildsystem of s390-tools. Since Rust comes with it's own buildsystem (Cargo), make simply calls into Cargo without any further interference.

Build requirements are:

• rustc
• Cargo

There is a new common_rust.mak file that defines all Cargo calls. Build targets are rust_build, rust_clean, and rust_test.
These are not supposed to be called directly. When working on Rust tools, Cargo should be used during development.
Per default, Cargo is called with the --quiet flag to avoid any noise in the pretty print of the make output. Specifying V=1 will display all Cargo output.

The pvinfo tool presented in this POC branch should be considered an example and is not supposed to be an official or upcoming tool.

This preview is primarily targeted towards distribution package maintainers to gather feedback for Rust related packaging.
@sharkcz @frank-heimes adding you for your awareness.

Please test and share your experience and let us know what could be improved to make it easier for packaging.

https://github.com/ibm-s390-linux/s390-tools/tree/rust

Release v2.29.0 now has Rust support: https://github.com/ibm-s390-linux/s390-tools/releases/tag/v2.29.0

[xnox]

In ubuntu we maintain rust toolchains in all releases, with regular updates to newer versions due to maintaining ability to build Firefox and Linux Kernel.

In general, Ubuntu welcomes use of rust in the system components and kernel.

Note that linux kernel currently only has x86 config spec file for rust support. It would be nice for kernel Z maintainers to basically copy LLVM config and integrate it with rust support.

[hoeppnerj]

So, I guess for Ubuntu this should work more or less out of the box and would be just a matter of correctly packaging the newly created binary.

Regarding the Kernel question, I could certainly mention it next time I talk to one of our Kernel maintainers. But here we're solely talking about userspace and how to integrated Cargo/Rust with the current buildsystem and packaging in distros.

[hoeppnerj]

@ngueorguiev fyi, I couldn't find your GitHub tag at first.

[sharkcz]

For completeness I will state that we don't have any network connectivity during the builds, so every dependency needs to resolve from the existing Fedora (or CentOS Stream or RHEL) repositories. I am expecting the new tools will require some Rust based libraries, but hopefully nothing too fancy :-)

[hoeppnerj]

Does that include no internal network, too? Because Cargo allows to configure repository locations other than crates.io via a config.toml file: https://doc.rust-lang.org/cargo/reference/config.html
Upcoming tools might have a couple of dependencies. Maybe local or internal mirrors might be a solution somehow (something we're thinking about, too).

[steffen-eiden]

The example tool/library are requiring some dependencies, pulled by default from crates.io. So you could test the dependency resolution.

The nature of rust-libraries consumed by other rust code is that their source-code is pulled from somewhere, compiled, and linked to the program statically (a rust-lib ABI is unstable). A rust program consists of its own code and some statically linked rust-libraries. C-libraries (OpenSSL, ...) are still linked dynamically (by default).

If you (can) do a prepare step with a network connection available you can issue a cargo fetch in that step. We can provide you with a Make target if required.

How do you do the dependency resolution with other rust projects for example Firefox?

Steffen

[xnox]

In Debian and Ubuntu, we package all build-dependencies as .deb packages; build-depend on them; symlink them to disk, and configure local mirror only pointing at the files fetches from the Apt Package archive and available on disk, offline before the build starts.

I believe this is similar in Fedora/Rhel as well. Meaning, you can browse existing catalogs of packages published and ideally limit yourselves to those. But also it shouldn't be too much of a problem to add new/more of those. Unless of course one goes off and starts to try to use all the packages at the same time.

But no, fetching things from the internet is prohibited. Vendoring all the dependencies in the source code is possible, but requires explicit exception request. Thus best to use common/well supported packages when possible. And ensure you did keep up with any upstream changes (keep yourself compatible with any api breaks in the dependencies).

[sharkcz]

The build environment is prepared from Fedora content before the actual build starts, naturally with internal network enabled, based on "BuildRequires" which can be resolved also dynamically (used eg. in Rust). But the build itself (like when running "make") has no network connectivity.

For the record, https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/ is how our Rust content is packaged. But I need to figure out how it applies for packages that mix content in C/C++,... with Rust, but I don't think s390utils would be the first project mixing source code. I believe Firefox bundles all their Rust deps in their sources.

[jcajka]

I would add from the (Fedora) distro perspective that it would be best to have minimal(no) dependency footprint beyond the standard library. I think that it would universally help with the maintainability and compatibility of the code, even beyond the distribution packaging.

If I'm not mistaken(I have more of Go background. At least on the distro packaging side it shares lot of same problems with Rust) it is the current state of the Rust bits that are proposed, right?

[steffen-eiden]

@sharkcz @frank-heimes @ngueorguiev

Have you had any time to test if you can build a package with the resources we gave you?
If no, what do you miss?

[xnox]

I managed to build pvinfo, on Ubuntu, using debcargo / dh-cargo and all dependencries from the ubuntu archive itself (i.e. without access to crates.io / using OS provided dependencies). All of them look trivial, some of them are missing on Jammy, but that can be solved with a couple of SRUs or by vendoring deps.

I am happy with this as is. I have no concerns about the dependencies you are using, or if you want to add more dependencies in the future. There is no need for you to restrict yourself in any way. Ubuntu is more rust friendly than Fedora ;-)

Note about use of workspace:
I understand the desire of using "workspace" for development in git. And for example automatic rust packaging tools in Debian & Ubuntu do not quite handle those directly, or like anything that has Cargo.toml not as a top-level package. Thus automation wise, it would have been easier for me to automatically package the crates if the "pv" and "pvinfo" were released as regular crate tarballs to crates.io at their respective versions of 0.1.0 and 0.9.0. As then I would just be able to call debcargo on both of them, to populate them as standalone packages with near zero effort or review. Once you merge this, it would be nice if you could as part of your release process, simply release rust crates into crates.io / or in addition to s390-tools tarball. Then packaging wise src:s390-tools would only build C things, and I would package the crates as separate src:rust-pv src:rust-pvinfo source packages, and add Depends on them from the s390-tools package to have them always available. This would also allow for rapid packaging, release, stable updates of the rust programmes compared with the C ones and those that have to go through signing process.

[steffen-eiden]

That is great!
We will discuss the crates.io packaging. IMO this sounds like a good idea.
Would that also work if C code depends on some s390-tools rust code (or vice versa)?

[steffen-eiden]

I dropped the workspace.
However, I cannot promise that we will upload the crates to crates.io immediately with the initial s390-tools rust release.
But I think it is a good idea to have them there.

[steffen-eiden]

@xnox @sharkcz @frank-heimes @ngueorguiev

Do you care about Cargo.lock files.
Or do you update the Cargo.lock files before you want to trigger a build anyways.

If you do not use the Cargo.lock files I am thinking about not publishing them to reduce the maintenance efforts.

[xnox]

in Ubuntu, if it is there we do use it, but also we then patch them in place if things are out of hand, if they are not there and you don't want to enforce or care or support particular ones that's fine too. However, in that case I hope you do have github action setup to continuously verify that builds still work against "latest" versions of crates.

[jcajka]

We do care about them, it is also preferred(expected) to have dependencies available vendored in the tree, especially if this will stay as "workspace" repo. I second the request for the standalone standard crates, repos.

[steffen-eiden]

In the updated rust branch the workplace approach is dropped.
The tools have a Cargo.lock file.

And as you expect them to be there, I think they should stay there.

[hoeppnerj]

It's also officially recommended to check in Cargo.lock for tools (aka binaries at the end of the dependency chain): https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries
Therefore we should definitely keep it.

[jcajka]

Sorry by "workspace" I mean bunch of crates in the directory what is in the latest rust branch. Vendored deps would by much appreciated, the same standalone standard crates(repos).

[hoeppnerj]

We've just pushed the recent changes of our Rust integration to the rust branch: https://github.com/ibm-s390-linux/s390-tools/tree/rust

The branch now also includes the preview of the new tool pvsecret which is written entirely in Rust and is used to manage secrets for IBM Secure Execution guests. Let us know if the builds and packaging still works as with the earlier versions. A list of dependencies and some guidelines around the Rust integration can be found in the Readme.

[jcajka]

Great, I have missed that in the zerocopy repo. Do you have a link?

https://copr.fedorainfracloud.org/coprs/jcajka/rusted-s390-utils/ built successfully for Fedora. We will have to introduce the zerocopy. Small note, nitpick as the new commands lack manpages make install fails, but it is easily workaroundable and I assume known and expected for WIP.

[steffen-eiden]

See my issue: google/zerocopy#199

I noticed the manpage issue as well after publishing the rust preview.
It will be fixed in the release. Thanks!

[hoeppnerj]

@jcajka I'm trying to get our daily build running for Fedora 38 with your spec file as a base. But as you've mentioned already the zerocopy crate is not packaged and that's exactly the issue I'm running into at the moment:

No matching package to install: 'crate(zerocopy)'    
Package gawk-5.1.1-5.fc38.s390x is already installed.
Package gzip-1.12-3.fc38.s390x is already installed. 
Package sed-4.8-12.fc38.s390x is already installed.  
Not all dependencies satisfied                       
Error: Some packages could not be found.             
Child return code was: 1                             
kill orphans                                         
child environment: None                              

How did you manage to get the build running?
Also, I was playing around with %generate_buildrequires and %cargo_generate_buildrequires but mock errors out because the scriptlets can't find Cargo.toml. I reckon those are supposed to be used for pure/single Rust porjects/crates?

[jcajka]

You can directly grab the spec from the copr https://download.copr.fedorainfracloud.org/results/jcajka/rusted-s390-utils/fedora-rawhide-s390x/06216923-s390utils/s390utils.spec

Generally just identifying the deps(pulled in via crate(...)) and using the %cargo_prep macro in %prep that setups local distro crate repo and compiler flags. Build itself is handled by unmodified make. I have to yet check that all the rustc flags are set per the guidelines. The way how s390utils uses rust is not covered explicitly by Fedora's rust guidelines, they are build around crate, not really around workspace or "workspace"(crates) mixed in the traditional project source tree. My spec should be in general spirit of the whole guidelines. IMHO workspace approach would be better in this case, but if Debian and Ubuntu can't work with it I guess it is fine, how it is now.

Again I would like to mention my ask for the vendored dependencies for the next iteration(they will be needed on the enterprise side). Either having them in git or just in release tarball would be much appreciated. IMHO there should be value for both end consumer and upstream in having them vendored in(and make set up to use them instead of pulling deps from internet).

[hoeppnerj]

You can directly grab the spec from the copr https://download.copr.fedorainfracloud.org/results/jcajka/rusted-s390-utils/fedora-rawhide-s390x/06216923-s390utils/s390utils.spec

I've used that spec file. But as I said I'm running into the issue that the crate(zerocopy) dependency can't be satisfied. And since you've mentioned the build is working for you nonetheless, I was wondering what you did differently. Did you use a custom zerocopy rpm or something? Maybe I'm missing some configuration details on our side, too.

Generally just identifying the deps(pulled in via crate(...)) and using the %cargo_prep macro in %prep that setups local distro crate repo and compiler flags. Build itself is handled by unmodified make. I have to yet check that all the rustc flags are set per the guidelines. The way how s390utils uses rust is not covered explicitly by Fedora's rust guidelines, they are build around crate, not really around workspace or "workspace"(crates) mixed in the traditional project source tree. My spec should be in general spirit of the whole guidelines. IMHO workspace approach would be better in this case, but if Debian and Ubuntu can't work with it I guess it is fine, how it is now.

Interesting that s390-tools seems to be one of the first (?) to use Cargo/Rust this way. I thought for example Firefox is doing that already and that distros would've faced potential packaging issues there already.

Again I would like to mention my ask for the vendored dependencies for the next iteration(they will be needed on the enterprise side). Either having them in git or just in release tarball would be much appreciated. IMHO there should be value for both end consumer and upstream in having them vendored in(and make set up to use them instead of pulling deps from internet).

I've started looking into that and I feel like we should definitely do that. It won't be part of the upcoming release though. I have yet to figure out all the details and possible implications.

[jcajka]

You can directly grab the spec from the copr https://download.copr.fedorainfracloud.org/results/jcajka/rusted-s390-utils/fedora-rawhide-s390x/06216923-s390utils/s390utils.spec

I've used that spec file. But as I said I'm running into the issue that the crate(zerocopy) dependency can't be satisfied. And since you've mentioned the build is working for you nonetheless, I was wondering what you did differently. Did you use a custom zerocopy rpm or something? Maybe I'm missing some configuration details on our side, too.

Yup, new packages are needed. They are in that COPR repo too. Just grab them there via builds/repofile or you can install them locally after enabling that copr repodnf copr enable jcajka/rusted-s390-utils.

Generally just identifying the deps(pulled in via crate(...)) and using the %cargo_prep macro in %prep that setups local distro crate repo and compiler flags. Build itself is handled by unmodified make. I have to yet check that all the rustc flags are set per the guidelines. The way how s390utils uses rust is not covered explicitly by Fedora's rust guidelines, they are build around crate, not really around workspace or "workspace"(crates) mixed in the traditional project source tree. My spec should be in general spirit of the whole guidelines. IMHO workspace approach would be better in this case, but if Debian and Ubuntu can't work with it I guess it is fine, how it is now.

Interesting that s390-tools seems to be one of the first (?) to use Cargo/Rust this way. I thought for example Firefox is doing that already and that distros would've faced potential packaging issues there already.

They either vendor the dependencies or use minimal external dependencies in rust or both.

Again I would like to mention my ask for the vendored dependencies for the next iteration(they will be needed on the enterprise side). Either having them in git or just in release tarball would be much appreciated. IMHO there should be value for both end consumer and upstream in having them vendored in(and make set up to use them instead of pulling deps from internet).

I've started looking into that and I feel like we should definitely do that. It won't be part of the upcoming release though. I have yet to figure out all the details and possible implications.

Thank you. :) I have been trying to hack something together within the Fedora packaging framework, but I haven't had much success yet. I need to do a deeper dive on the rustc/cargo's config structure and inheritance.

[jcajka]

Awesome, just picked that up. I will work with @sharkcz in getting that in to Fedora asap. Thank you.

[jcajka]

Unfortunately it seems that there are currently some dependency issue in Fedora for the zerocopy as Fedora moved forward to trybuild 1.0.82 from 1.0.80 that zerocopy requires in v0.6.3. Will see what can be done.

[jcajka]

Fortunately seem workaround-able via unpinning the required version in Cargo file. Sill the tests have to be disabled as it seems that the tests are dependent on certain error formatting tied to the compiler version, at least that is my guess. Or is it a fall out of using "wrong" version of trybuild?
Log from x86_64.

EXPECTED:
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
error[E0277]: the trait bound `*const usize: AsBytes` is not satisfied
  --> tests/ui-stable/transmute-illegal.rs:10:30
   |
10 | const POINTER_VALUE: usize = zerocopy::transmute!(&0usize as *const usize);
   |                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `AsBytes` is not implemented for `*const usize`
   |
   = help: the following other types implement trait `AsBytes`:
             f32
             f64
             i128
             i16
             i32
             i64
             i8
             isize
           and $N others
note: required by a bound in `POINTER_VALUE::transmute`
  --> tests/ui-stable/transmute-illegal.rs:10:30
   |
10 | const POINTER_VALUE: usize = zerocopy::transmute!(&0usize as *const usize);
   |                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ required by this bound in `POINTER_VALUE::transmute`
   = note: this error originates in the macro `zerocopy::transmute` (in Nightly builds, run with -Z macro-backtrace for more info)
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈

ACTUAL OUTPUT:
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
error[E0277]: the trait bound `*const usize: AsBytes` is not satisfied
  --> tests/ui-stable/transmute-illegal.rs:10:30
   |
10 | const POINTER_VALUE: usize = zerocopy::transmute!(&0usize as *const usize);
   |                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |                              |
   |                              the trait `AsBytes` is not implemented for `*const usize`
   |                              required by a bound introduced by this call
   |
   = help: the trait `AsBytes` is implemented for `usize`
note: required by a bound in `POINTER_VALUE::transmute`
  --> tests/ui-stable/transmute-illegal.rs:10:30
   |
10 | const POINTER_VALUE: usize = zerocopy::transmute!(&0usize as *const usize);
   |                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ required by this bound in `transmute`
   = note: this error originates in the macro `zerocopy::transmute` (in Nightly builds, run with -Z macro-backtrace for more info)
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
note: If the actual output is the correct output you can bless it by rerunning
      your test with the environment variable TRYBUILD=overwrite



test ui ... FAILED

[steffen-eiden]

I think this is a fallout from picking another version. I guess zerocopy didn't fix the version of that crate for fun.

I'll investigate this, and might submit an issue to zerocopy.

[steffen-eiden]

OK just found out why they pinned it.
They expect a specific format that might change during minor/patch version changes.
See: https://github.com/google/zerocopy/blob/main/Cargo.toml#L54

So you where right.
it seems that the tests are dependent on certain error formatting tied to the compiler version

[sharkcz]

for the record, librsvg2 is an example that contains Rust source code, provides a normal shared library and uses a classic build system, see https://src.fedoraproject.org/rpms/librsvg2/blob/rawhide/f/librsvg2.spec

[hoeppnerj]

fyi, release v2.29.0 now has Rust support: https://github.com/ibm-s390-linux/s390-tools/releases/tag/v2.29.0
The rust branch with the preview has been removed. I've updated the information in the initial conversion post.

[ngueorguiev]

Hello,

When I am trying to build pvsecret in release mode:

error: env 'S390_TOOLS_RELEASE' must be set for release builds. Trigger build using the s390-tools build system or export the variable yourself
  --> src/main.rs:56:9
   |
56 |         release_string!()
   |         ^^^^^^^^^^^^^^^^^
   |
   = note: this error originates in the macro `env` which comes from the expansion of the macro `release_string` (in Nightly builds, run with -Z macro-backtrace for more info)

error: could not compile `pvsecret` (bin "pvsecret") due to previous error

The s390-tools are in the latest version 2.29.0. Is it "normal" or "as expected"?

Thanks.

[steffen-eiden]

It seems like you are directly (or indirectly) invoking cargo without using the s390-tools makefiles. Is that correct?
In that case you need to have an environment variable S390_TOOLS_RELEASE present with the s390-tools version string.
Use make version to get the version string. See rust/README

Or do you use make to build pvsecret?

Steffen

[ngueorguiev]

I am using Open Build Services' .spec file for whole s390-tools build; plus invoking cargo build directly for test purposes.

Could you please tell me what the pvsecret expects as an environment variable (0 or 2.29.0 or s2290 or something else)?

Thanks.

[steffen-eiden]

Technically, you could use any string for S390_TOOLS_RELEASE, but it should be the same as for the C programs.
It is built at common.mak

If you do the following the rust programs have the same version as the C programs.
In the s390-tools directory

$ export S390_TOOLS_RELEASE=$(make version)
$ cd rust/pvsecret
$ cargo b --release
   [...]
$ ./target/release/pvsecret --version
pvsecret version 2.29.0-build-20230807
Copyright IBM Corp. 2023

Version string with the latest master, today, your version string may vary.

[ngueorguiev]

Thanks! The make to build pvsecret is working fine.