I am all in for Rust in the kernel (as drivers) and I am really curious of how they will manage sharing memory across boundaries (user <--> kernel spaces). For

I am all in for Rust in the kernel (as drivers) and I am really curious of how they will manage sharing memory across boundaries (user <--> kernel spaces). For example, an H264 encoder/decoder module in the kernel: let's say I have a Freescale/NXP i.MX6 platform with a HW H264 decoder, and I have to create kernel module to talk to it. Then use this module from an user space application to decode a video file. What I did (modified actually) in the past is a module that allocated a couple of (aligned) buffers in video memory and then passed them around between the HW decoder, kernel module and user space application. This is usually done to not force a deep copy of >100KB buffer for every decoded frame. This memory is shared between different parts of the implementation, meaning that the same buffer belongs to up to 3 parties at any given time. Also, the allocation is done once and lives for the entire application life, usually allocating like 3 buffer so when one buffer is being decoded I can still use already decoded buffers for writing them into a file. I know there is an alternative (hack?) using something called Pin (possibly clashing with, like, a GPIO Pin?) but I didn't get so deep already with Rust to really understand it. Ah! whatever driver/module they do, it should be accessible with C. So Rust must fill the gap between "Some C code in userland" <--> Rust <--> "More C code in the kernel", so I'm really interested to see how ownership works in this case. Userland C app says: "Hey Rust kernel module, take this struct and do something", the I go and change the contents of that struct from another thread in my userland application. Would this be possible?