- Devel - lists.tockos.org

Type-safe syscall exploration
by Johnathan Van Why Nov. 19, 2024

Nov. 19, 2024

Inspired by the ongoing discussions about porting Tock to CHERI, I wrote down some ideas on how to make Tock's syscall ABI more type-safe. The writeup is in the design-explorations repository at Add an exploration of type-safe system calls <https://github.com/tock/design-explorations/pull/4>. While I'm not suggesting that we should start on Tock 3.0 now, I do think we should incorporate some of the design ideas into Tock 3.0 when it happens. A secondary goal of the document is to spread knowledge about CHERI. Feel free to take a look, and either reply with feedback here or comment on the PR. -Johnathan

2 2

Tock meeting agenda 2024-11-15
by Amit Levy Nov. 15, 2024

Nov. 15, 2024

Meeting link: https://meetings.dialpad.com/room/tock/1vnk9r3e1b Agenda - Updates - TockWorld format and timing - x86 upstreaming: fresh rewrite or vendored crate - `usize` in ABI -comments PRs #4228 and #4229 - Crypto WG proposal

1 0

Call for Tock meeting agenda items 2024-11-15
by Amit Levy Nov. 14, 2024

Nov. 14, 2024

Please respond with any agenda items for tomorrow's call.

1 1

Tock meeting agenda 2024-11-08
by Amit Levy Nov. 8, 2024

Nov. 8, 2024

Today will be shorter than normal meeting to make time for a focused discussion of some PRs after. Meeting link: https://meetings.dialpad.com/room/tock/1vnk9r3e1b Agenda - Updates - EWSN Tutorial - Implications of `cortex-m4f` crate - https://github.com/tock/tock/pull/4224

1 0

Call for Tock meeting agenda items 2024-11-8
by Amit Levy Nov. 8, 2024

Nov. 8, 2024

Please respond with any agenda items for tomorrow's call.

2 1

Call for Tock meeting agenda items 2024-11-1
by Amit Levy Oct. 31, 2024

Oct. 31, 2024

Please respond with any agenda items for tomorrow's call.

1 0

Call for Tock meeting agenda items 2024-10-25
by Amit Levy Oct. 25, 2024

Oct. 25, 2024

Please respond with any agenda items for today's call.

2 1

Tock meeting agenda 2024-10-18
by Branden Ghena Oct. 18, 2024

Oct. 18, 2024

Meeting link: https://meetings.dialpad.com/room/tock/1vnk9r3e1b Agenda - Updates - Tock Release, Treadmill, and you! - Process Slice Buffered API: https://github.com/tock/tock/pull/4023

1 0

Call for Tock meeting agenda items 2024-10-18
by Branden Ghena Oct. 18, 2024

Oct. 18, 2024

Please respond with any agenda items for today's call. Thanks, Branden Ghena Northwestern University

2 2

Looking for Insights on Tock's Context Switch Latency
by zhiyao.ma.98＠gmail.com Oct. 17, 2024

Oct. 17, 2024

Hello Tock developers, I am recently testing Tock's context switch speed with an STM32F412G-Discovery board, and I noticed that the latency is longer than expected. I hope to confirm that my settings are correct and gain some insights behind the data. To test the context switch speed, I implemented two apps called "server" and "client." The server sets up an IPC service that simply notifies completion back to the client. The client invokes the IPC service 10,000 times in a loop and then calculates the average ping-pong time. On my board, the 10,000 ping-pong takes 10,748 ms. That is more than 1ms for each ping-pong. I believe the CPU clock is set to 96 MHz by the default kernel configuration for the board. With a similar clock speed, a ping-pong implemented through task notification on FreeRTOS takes around 13 μs, which is almost two orders of magnitude faster than Tock. Professor Campbell pointed out to me that there are multiple context switches for each ping-pong: On the "client" side: - calls command() -> context switch to the kernel - command returns -> context switch back to the client app - client app calls yield -> context switch back to the kernel Next, on the “server” side: - upcall scheduled -> context switch to the server app - calls ipc_notify_client -> context switch to the kernel to schedule the upcall - command returns -> context switch back to the server app - yield -> context switch to the kernel Finally, on the “client” side again: - upcall scheduled -> context switch to the client app However, even if there are 8 context switches per ping-pong, on average each context switch still takes around 135 μs, which is around 13k instructions executed per context switch on a 96 MHz CPU. The number still seems to be high. Below is the source code for the “server” and “client” app. Server: ```c #include <libtock/kernel/ipc.h> #include <libtock/tock.h> static void ipc_callback( int pid, __attribute__ ((unused)) int len, __attribute__ ((unused)) int buf, __attribute__ ((unused)) void* ud) { ipc_notify_client(pid); } int main(void) { ipc_register_service_callback("server", ipc_callback, NULL); while (1) { yield(); } } ``` Client: ```c #include <stdio.h> #include <libtock-sync/services/alarm.h> #include <libtock/kernel/ipc.h> size_t service_id = -1; char buf[64] __attribute__((aligned(64))); bool done = false; static void ipc_callback(__attribute__ ((unused)) int pid, __attribute__ ((unused)) int len, __attribute__ ((unused)) int arg2, __attribute__ ((unused)) void* ud) { done = true; } static uint32_t get_time_ms(void) { struct timeval tv; libtock_alarm_gettimeasticks(&tv, NULL); return (tv.tv_sec * 1000) + (tv.tv_usec / 1000); } int main(void) { int ret; ret = ipc_discover("server", &service_id); while (ret != RETURNCODE_SUCCESS) { printf("No server, retry in 1 second.\n"); libtocksync_alarm_delay_ms(1000); } printf("Server discovered.\n"); ipc_register_client_callback(service_id, ipc_callback, NULL); ipc_share(service_id, buf, 64); uint32_t start_time = get_time_ms(); for (int i = 0; i < 10000; ++i) { done = false; ipc_notify_service(service_id); yield_for(&done); } uint32_t end_time = get_time_ms(); printf("Ping-pong 10000 times take %lu ms.\n", end_time - start_time); return 0; } ```

4 8