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