• Home
  • History
  • Annotate
Name Date Size #Lines LOC

..--

collections/06-Mar-2024-160124

vec/06-Mar-2024-4,7921,951

README.mdD06-Mar-20241.6 KiB3727

alloc.rsD06-Mar-202415.1 KiB429234

boxed.rsD06-Mar-202477.1 KiB2,452999

lib.rsD06-Mar-20249.4 KiB288190

raw_vec.rsD06-Mar-202422.7 KiB575304

slice.rsD06-Mar-202430.7 KiB891469

README.md

1# `alloc`
2
3These source files come from the Rust standard library, hosted in
4the <https://github.com/rust-lang/rust> repository, licensed under
5"Apache-2.0 OR MIT" and adapted for kernel use. For copyright details,
6see <https://github.com/rust-lang/rust/blob/master/COPYRIGHT>.
7
8Please note that these files should be kept as close as possible to
9upstream. In general, only additions should be performed (e.g. new
10methods). Eventually, changes should make it into upstream so that,
11at some point, this fork can be dropped from the kernel tree.
12
13The Rust upstream version on top of which these files are based matches
14the output of `scripts/min-tool-version.sh rustc`.
15
16
17## Rationale
18
19On one hand, kernel folks wanted to keep `alloc` in-tree to have more
20freedom in both workflow and actual features if actually needed
21(e.g. receiver types if we ended up using them), which is reasonable.
22
23On the other hand, Rust folks wanted to keep `alloc` as close as
24upstream as possible and avoid as much divergence as possible, which
25is also reasonable.
26
27We agreed on a middle-ground: we would keep a subset of `alloc`
28in-tree that would be as small and as close as possible to upstream.
29Then, upstream can start adding the functions that we add to `alloc`
30etc., until we reach a point where the kernel already knows exactly
31what it needs in `alloc` and all the new methods are merged into
32upstream, so that we can drop `alloc` from the kernel tree and go back
33to using the upstream one.
34
35By doing this, the kernel can go a bit faster now, and Rust can
36slowly incorporate and discuss the changes as needed.
37