On 5/30/25 02:27, Bo Li wrote: > Changelog: > > v2: > - Port the RPAL functions to the latest v6.15 kernel. > - Add a supplementary introduction to the application scenarios and > security considerations of RPAL. > > link to v1: > https://lore.kernel.org/lkml/CAP2HCOmAkRVTci0ObtyW=3v6GFOrt9zCn2NwLUbZ+Di49xkBiw@xxxxxxxxxxxxxx/ > Okay, First of all, I agree with most of the other reviewers that this is insane. Second of all, calling this "optimize cost of inter-process communication" is *extremely* misleading, to the point that one could worry about it being malicious. What you are doing is attempting to provide isolation between threads running in the same memory space. *By definition* those are not processes. Secondly, doing function calls from one thread to another in the same memory space isn't really IPC at all, as the scheduler is not involved. Third, this is something that should be possible to do entirely in user space (mostly in a modified libc). Most of the facilities that you seem to implement already have equivalents (/dev/shm, ET_DYN, ld.so, ...) This isn't a new idea; this is where the microkernel people eventually ended up when they tried to get performant. It didn't work well for the same reason -- without involving the kernel (or dedicated hardware facilities; x86 segments and MPK are *not* designed for this), the isolation *can't* be enforced. You can, of course, have a kernel interface to switch the address space around -- and you have just (re)invented processes.
