Vadím Sukhomlínov

I also like an approach, but thinking about how call site will look like, it seems like there is overhead in preparing a struct. Yes, overall it will be faster,...

This change to be useful should also result in code size savings. Benefits from avoiding many syscalls are only in avoidance of context saving/restoring which is relatively cheap and potential...

@alexandruradovici thanks for measurements! it is good if code bloat will remain small. There are few things which makes me thing code size on caller site can grow - filling...

> 1. Quantifying the exact cost these syscall patterns have and their impact on applications. @vsukhoml has mentioned some crypto use cases that involve ~5 allows on each side of...

By *performance* I mean wall clock time overhead to complete sequence of allow/subscribe/command/yield/unsubscribe/unallow vs. time to actually perform a function. In case of command being 'async' in kernel and upcall...

i think there is potential to reduce syscall overhead down to 50-100 cycles by streamlining storing/restoring context and reducing it to RISC-V ABI conventions on syscalls (don't save caller-saved regs).

It may be more efficient to pass Page by value than by reference into read()/write() - this struct is lightweight and will be passed as 2 regular arguments. AccessControlConfig can...

In order to make it useful in multi-application scenario, filesystem/store should also implement access control lists for keys and persistent ids for applications to define acls. Also, regarding keys -...

where the need for relocatable kernel (-C relocation-model=dynamic-no-pic ) come from? it impacts code size and inhibits linker relaxation (use of __global_pointer and (gp) based addressing on RISC-V). Also, as...

When I removed -C relocation-model=dynamic-no-pic - it seems there is some redistribution between .text and .data, but simple kernel i tried worked. It didn't enable gp-based addressing on RISC-V though.