On Wed, Sep 21, 2022 at 02:23:42PM +0300, Konstantin Shelekhin wrote: > On Sat, Aug 06, 2022 at 01:22:52PM +0200, Miguel Ojeda wrote: > > On Sat, Aug 6, 2022 at 12:25 PM Konstantin Shelekhin > > <k.shelekhin@xxxxxxxxx> wrote: > > > > > > I sense possible problems here. It's common for a kernel code to pass > > > flags during memory allocations. > > > > Yes, of course. We will support this, but how exactly it will look > > like, to what extent upstream Rust's `alloc` could support our use > > cases, etc. has been on discussion for a long time. > > > > For instance, see https://github.com/Rust-for-Linux/linux/pull/815 for > > a potential extension trait approach with no allocator carried on the > > type that Andreas wrote after a discussion in the last informal call: > > > > let a = Box::try_new_atomic(101)?; > > In my opinion, the rest of the thread clearly shows that the > conservative approach is currently the only solid option. I suggest the > following explicit API: > > let a = Box::try_new(size, flags)?; > Vec::try_push(item, flags)?; > > etc. Whadda you think? Please, yes. This fits the current kernel memory allocation pattern and allows for proper propagation of the allocation flags as needed through the system. This is going to be required in any non-trivial kernel code anyway, might as well do it correct from the beginning. It also allows for flags to change over time, which also happens. thanks, greg k-h
