Skip to content

Commit cd8d764

Browse files
authored
Merge pull request #421 from ojeda/alloc-readme
rust: alloc: add `README.md`
2 parents 92c2f34 + 758f7dd commit cd8d764

File tree

1 file changed

+32
-0
lines changed

1 file changed

+32
-0
lines changed

rust/alloc/README.md

Lines changed: 32 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,32 @@
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

Comments
 (0)