|
| 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. |
0 commit comments