Tock OT Notes 3/06/2020

Present:

• Brad Campbell (Chair), University of Virginia
• Jon Flatley, Google
• Garret Kelly, Google
• Phil Levis, Stanford
• Silvestrs Timofejevs, lowRISC
• Alistair Francis, Western Digital

TODO

• Google: Share roadmap draft in the next week
• @bradjc: add Silvestrs to github team
• @phil-levis: open PR for space analysis tool

Roadmap

• Garret: in progress, outlines what Tock support for OT should look like in a year.
• Ideas: libtock-rs support, testing frameworks, crypto capsule, kernel size roughly 25 kB, performance analysis of syscalls, key-value store across updates, userspace I/O bypass.

Welcome to Silvestrs

• Silvestrs: at lowrisc, working on DIFs
• Getting up to speed with Tock and Rust
• Happy to help with specific projects

Meeting scheduling

• Not clear when to reschedule meeting to
• Please fill out the poll

Size of the Tock kernel

• Phil: There have been concerns over the size of the kernel, but what size do we want? How can we quantify this to see what the delta is and where effort should be directed?
• Garret: Our aspirational goal would be a 25 kB kernel.
• Right now, internal builds are around 40 kB, might be able to get to 30-35 kB.
• An alternative OS at Google is around 20 kB, so using that as a benchmark.
• Phil: What should be included in that 25 kB?
• Garret: Full set of drivers for all the peripherals.
• Brad: And what kernel features?
• Garret: Less clear, we will need to quantify that.
• Brad: Are there hardware size constraints?
• Garret: OT chip tentatively is 2x 512 kB of flash.
• However, we have previously ran out of flash, and are very motivated to avoid running out of flash.
• Also, some existing apps are quite large.
• Flash not only for kernel+apps, but also for data storage. And since the flash controller will cause a stall if same bank is used while code is executing from it, data are duplicated to both banks to avoid stalls, which effectively reduces available space.
• Still working on trying to get more concrete numbers of specific space needs across kernel, apps, and data.
• Brad: Will we be able to avoid wasted space for apps with the RISC-V PMP?
• Alistair: PMP is a lot more flexible and we should be able to avoid the MPU alignment issues.
• Alistair: What about the overhead in libtock-rs?
• Phil: Use libtock-c?
• Alistair: Not clear that is better.
• Garret: Is the overhead from unused drivers not being optimized out?
• Alistair: I haven't dug in, but there is definitely overhead in apps and not just in the kernel.
• Phil: Garret, are you using my tool for breaking down the flash usage of apps?
• Garret: I'm aware, not sure if we are using it.
• Phil: We used it to show that roughly 30% of a binary went to static data.
• Phil: I will make a PR to add the tool to the Tock repo.