On Wed, Apr 14, 2021 at 10:10 PM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > On Wed, Apr 14, 2021 at 08:45:51PM +0200, ojeda@xxxxxxxxxx wrote: > > - Manish Goregaokar implemented the fallible `Box`, `Arc`, and `Rc` > > allocator APIs in Rust's `alloc` standard library for us. > > There's a philosophical point to be discussed here which you're skating > right over! Should rust-in-the-linux-kernel provide the same memory > allocation APIs as the rust-standard-library, or should it provide a Rusty > API to the standard-linux-memory-allocation APIs? You seem to be doing > both ... there was a wrapper around alloc_pages() in the Binder patches, > and then you talk about Box, Arc and Rc here. Please see my reply to Linus. The Rust standard library team is doing work on allocators, fallible allocations, etc., but that is very much a WIP. We hope that our usage and needs inform them in their design. Manish Goregaokar implemented the `try_reserve` feature since he knew we wanted to have fallible allocations etc. (I was not really involved in that, perhaps somebody else can comment); but we will have to replace `alloc` anyway in the near feature, and we wanted to give Manish credit for advancing the state of the art there nevertheless. > Maybe there's some details about when one can use one kind of API and > when to use another. But I fear that we'll have Rust code at interrupt > level trying to use allocators which assume that they can sleep, and > things will go badly wrong. Definitely. In fact, we want to have all public functions exposed by Rust infrastructure tagged with the context they can work in, etc. Ideally, we could propose a language feature like "colored `unsafe`" so that one can actually inform the compiler that a function is only safe in some contexts, e.g. `unsafe(interrupt)`. But language features are a moonshot, for the moment we want to go with the annotation in the doc-comment, like we do with the `Safety` preconditions and type invariants. Cheers, Miguel
