On 8/26/2020 10:04 AM, Andy Lutomirski wrote:
On Wed, Aug 26, 2020 at 9:52 AM Florian Weimer <fweimer@xxxxxxxxxx> wrote:
* Dave Martin:
On Tue, Aug 25, 2020 at 04:34:27PM -0700, Yu, Yu-cheng wrote:
On 8/25/2020 4:20 PM, Dave Hansen wrote:
On 8/25/20 2:04 PM, Yu, Yu-cheng wrote:
I think this is more arch-specific. Even if it becomes a new syscall,
we still need to pass the same parameters.
Right, but without the copying in and out of memory.
Linux-api is already on the Cc list. Do we need to add more people to
get some agreements for the syscall?
What kind of agreement are you looking for? I'd suggest just coding it
up and posting the patches. Adding syscalls really is really pretty
straightforward and isn't much code at all.
Sure, I will do that.
Alternatively, would a regular prctl() work here?
Is this something appliation code has to call, or just the dynamic
loader?
prctl in glibc is a variadic function, so if there's a mismatch between
the kernel/userspace syscall convention and the userspace calling
convention (for variadic functions) for specific types, it can't be made
to work in a generic way.
The loader can use inline assembly for system calls and does not have
this issue, but applications would be implcated by it.
I would expect things like Go and various JITs to call it directly.
If we wanted to be fancy and add a potentially more widely useful
syscall, how about:
mmap_special(void *addr, size_t length, int prot, int flags, int type);
Where type is something like MMAP_SPECIAL_X86_SHSTK. Fundamentally,
this is really just mmap() except that we want to map something a bit
magical, and we don't want to require opening a device node to do it.
One benefit of MMAP_SPECIAL_* is there are more free bits than MAP_*.
Does ARM have similar needs for memory mapping, Dave?
Yu-cheng
