Brad Campbell

> If the callback is able to return different values to the syscall site in r0-r3, it might be useful for filtering or customizing the result... Is `Yield-WaitFor-CallbackIfPresent` either or,...

With `Yield-WaitFor-CallbackIfPresent`, is it true that userspace can't determine at runtime if r0-r3 are valid, or if an upcall executed? So libtock tries to write: ```c int my_command_sync() { driver_command();...

> > With Yield-WaitFor-CallbackIfPresent, is it true that userspace can't determine at runtime if r0-r3 are valid, or if an upcall executed? > > As currently written, this is correct,...

> I have a possible design for resolving this, mostly just throwing ideas out there: > > * yield-for takes an upcall pointer in `r2` and application data in `r3`,...

> * I followed @bradjc's thinking and updated the whole `Yield Syscall Class` to always/explicitly use r1 as a "yield result" mechanism — this addresses the "did a callback run?"...

Do we need a new error code? ```c int my_sync_syscall(int* len) { uint8_t yield_result command() yield_for(upcall_id, &yield_result) if (yield_result == 0) { *len = r2 return SUCCESS } else {...

I am opposed to `Yield-WaitFor-CallbackIfPresent`. It adds uncertainty to userspace for reasons I don't think are very important. I think the only argument in favor is that the relationship with...

> As a side note, one cool new feature this could enable is loading processes from (external) flash into RAM for chips or architectures that do not have XIP flash....

Porting to an architecture is challenging because it is not always obvious how to map Tock's expectations of context switches to what the actual hardware provides. The core of the...

This is only blocked on #3829 now.