mirror of https://github.com/torvalds/linux.git synced 2025-04-05 22:13:52 +00:00

Benno Lossin 2e5f4f3cf2 rust: pin-init: add miscellaneous files from the user-space version

Add readme and contribution guidelines of the user-space version of
pin-init.

Signed-off-by: Benno Lossin <benno.lossin@proton.me>
Reviewed-by: Fiona Behrens <me@kloenk.dev>
Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org>
Tested-by: Andreas Hindborg <a.hindborg@kernel.org>
Link: https://lore.kernel.org/r/20250308110339.2997091-21-benno.lossin@proton.me
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

2025-03-16 21:59:19 +01:00

3.4 KiB

Raw Permalink Blame History

Contributing to `pin-init`

Thanks for showing interest in contributing to pin-init! This document outlines the guidelines for contributing to pin-init.

All contributions are double-licensed under Apache 2.0 and MIT. You can find the respective licenses in the LICENSE-APACHE and LICENSE-MIT files.

Non-Code Contributions

Bug Reports

For any type of bug report, please submit an issue using the bug report issue template.

If the issue is a soundness issue, please privately report it as a security vulnerability via the GitHub web interface.

Feature Requests

If you have any feature requests, please submit an issue using the feature request issue template.

Questions and Getting Help

You can ask questions in the Discussions page of the GitHub repository. If you're encountering problems or just have questions related to pin-init in the Linux kernel, you can also ask your questions in the Rust-for-Linux Zulip or see https://rust-for-linux.com/contact.

Contributing Code

Linux Kernel

pin-init is used by the Linux kernel and all commits are synchronized to it. For this reason, the same requirements for commits apply to pin-init. See the kernel's documentation for details. The rest of this document will also cover some of the rules listed there and additional ones.

Contributions to pin-init ideally go through the GitHub repository, because that repository runs a CI with lots of tests not present in the kernel. However, patches are also accepted (though not preferred). Do note that there are some files that are only present in the GitHub repository such as tests, licenses and cargo related files. Making changes to them can only happen via GitHub.

Commit Style

Everything must compile without errors or warnings and all tests must pass after every commit. This is important for bisection and also required by the kernel.

Each commit should be a single, logically cohesive change. Of course it's best to keep the changes small and digestible, but logically linked changes should be made in the same commit. For example, when fixing typos, create a single commit that fixes all of them instead of one commit per typo.

Commits must have a meaningful commit title. Commits with changes to files in the internal directory should have a title prefixed with internal:. The commit message should explain the change and its rationale. You also have to add your Signed-off-by tag, see Developer's Certificate of Origin. This has to be done for both mailing list submissions as well as GitHub submissions.

Any changes made to public APIs must be documented not only in the commit message, but also in the CHANGELOG.md file. This is especially important for breaking changes, as those warrant a major version bump.

If you make changes to the top-level crate documentation, you also need to update the README.md via cargo rdme.

Some of these rules can be ignored if the change is done solely to files that are not present in the kernel version of this library. Those files are documented in the sync-kernel.sh script at the very bottom in the --exclude flag given to the git am command.

3.4 KiB Raw Permalink Blame History

Contributing to pin-init