Messages in this thread | | | Date | Sat, 6 Aug 2022 15:57:35 +0100 | From | Matthew Wilcox <> | Subject | Re: [PATCH v9 12/27] rust: add `kernel` crate |
| |
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@yadro.com> 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)?;
Something I've been wondering about for a while is ...
struct task_struct { ... + gfp_t gfp_flags; ... };
We've already done some work towards this with the scoped allocation API for NOIO and NOFS, but having spin_lock() turn current->gfp_flags into GFP_ATOMIC might not be the worst idea in the world.
| |