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