Back to Tock

Tock Core Notes 2021-01-22

doc/wg/core/notes/core-notes-2021-01-22.md

latest9.0 KB
Original Source

Tock Core Notes 2021-01-22

Attending

  • Pat Pannuto
  • Amit Levy
  • Alistair
  • Leon Schuermann
  • Arjun Deopujari
  • Philip Levis
  • Johnathan Van Way
  • Hudson Ayers
  • Brad Campbell
  • Branden Ghena
  • Gabe Marcano
  • Vadim Sukhomlinov

Updates

  • phil: 33/43 syscalls; yield done; 10 more drivers and exit is that last of the todo list -- I'm starting to pick up some of the last lingering ones to get it out the door
  • brad: following up on last week's 'initial RAM' discussion: it's really a historical artifact that the kernel tracks the stack pointer at all; but that's more an arch-specific thing; I have a WIP branch that pulls it into arch-specific code rather than core process.rs ;; It's a simpler conceptual thing, but it ends up touching a lot of code; PR needs testing
  • pat: Introducing Gabe Marcano, PhD student @ UCSD, will be working on a benchmarking project

Testing of syscalls only supported on libtock-rs

  • phil: Might have a quick answer, as there's a PR from Johnathan
  • johnathan: Sadly no, that's on the re-write side of the line
  • phil: The challenege here is that while Alistair has been doing a great job of porting things, we have devices with no libtock-c support but libtock-rs doesn't yet have 2.0 support, can (1) implement in libtock-c, (2) get 2.0 working in libtock-rs, (3) cut the drivers
  • amit: 4th option? delay testing
  • phil: that feels like a non-option; compiling but untested code in main is not great
  • alistair: are we planning to release 2.0 prior to userspace support in libtock-rs?
  • amit: maybe a question for johnathan? though it would be unfortunate to block one of the libtock-rs 2.0 vs kernel 2.0
  • johnathan: it's kind of a race between me and the rest of the core team for the respective 2.0's
  • johnathan: on the one hand, don't want to block kernel.. on the other, do have strong work incentive to have libtock-rs 2.0 ready on ~1month timeline
  • amit: is it reasonable / viable to get some of the person-power from the core team moving from kernel to libtock-rs, now that kernel is close? caveat: you (johnathan) would have to project manage that a bit
  • johnathan: maybe.. there's a lot of interrelated things that a WIP that I need to get out. Need to get the driver infra written, but once it's about porting drivers, that should be well-suited
  • amit: what are the drivers that are unique to libtock-rs?
  • phil: think they are HMAC and CTAP (alistair confirms)
  • leon: I think I can write a libtock-c driver for HMAC [alistair also willing; it's the simpler one]
  • amit: for CTAP, how much deep USB knowledge does one need for a C driver?
  • alistair: in libtock-rs, we use the CTAP crate... fair bit of work
  • phil: but all we really have to do is test the system calls.. right?
  • alistair: yes, but won't get meaningful subscribes without sending the right data/events -- really need it all
  • phil: in this particular case, the thing we are trying to test isn't the full CTAP functoinality, but the implementation of the system calls...
  • alistair: yes, but if you don't send valid data, you won't get valid data
  • amit: very difficult to write a test that covers syscalls without implement much of the stack
  • phil: can we hardcode one set of messages?
  • pat: can we complie CTAP crate as an object to link with C?
  • amit: no, reloaction strategy difference between llvm and gcc
  • vadim: also problems with static linking of libraries and mixed toolchains (missed some of the details here) -- for one specific use case, you can make it work
  • johnathan: maybe a miscommunication here between vadim and amit here -- llvm folks say it's not possible
  • amit: I might buy that with static libraries it's possible in some but not all cases
  • johnathan: it should be doable with statically linked binaries with libtock-c's risc-v support?
  • amit: don't really have a risc-v platform with USB, except maybe Open Titan?
  • alistair: ...kind of; OT USB is broken, would have to revert a bunch
  • amit: summary: CTAP in C userland is pretty high effort; some possible shortcuts available, but don't want to rely on them to get 2.0 out the door
  • amit: options: tie to libtock-rs, or be okay with this one driver being untested, or sequester this driver
  • hudson: 4th proposal: my understanding is that tock-2.0-dev is not mainline, it's a feature branch; can commit untested code there. Right now there's still a possibility that libtock-rs-2.0 beats kernel 2.0. Proposal: we should just merge this untested so that the purging of old driver infra can occur in that branch. We add this to a list of things that need to be resolved on 'actual 2.0'
  • leon: I agree with the state of 2.0 branch; many of the changes there only tested in isolation -- I had been imagining a 'big test' event near 2.0
  • phil: sounds good/okay to kick the can for now
  • phil: opens the Q about what happens when 2.0 is ready, but we have capsule code that's untested/untestable -- what should our policy/plan be?
  • leon: leave it out until it's tested?
  • phil: it's okay to have not-well-tested code in the repository, just needs to be clear (i.e. a capsules-dev/ folder?)
  • leon: brings back an old Q about 'support levels for capsules'; the dev folder is a simple form of that
  • amit: indeed; though maybe we can keep punting on the big question if it's just 1-2 capsules that will only be in the -dev state for small N months
  • phil: I worry about the signpost capsules in the same way -- what happens where there's no signpost hardware?
  • phil: don't want to give impression that signpost code is as tested as console
  • phil: not a problem for today, but we need to keep in mind
  • phil: conclusion: okay to merge to 2.0 branch for now; will re-assess when we merge 2.0 back to mainline
  • amit: conclusion: will need a clear label for untested, will not throw away
  • leon: really should apply to all capsules that aren't tested on the merged result [even things tested along the way to 2.0]
  • alistair: can try to write some simple, partial CTAP tests to help this out along the way
  • alistair: if anyone has imix hardware, can they test USB?
  • phil: I will try.
  • phil: What USB is exposed on imix?
  • amit: There's the little unix utility that Daniel wrote to interface with imix as a (raw bulk?) device
  • phil: you get that over target?
  • amit: yes, need to plug in both cables
  • amit: tool is in tools/usb -- bulk echo, bulk echo test, etc
  • brad: and need to flash a userspace app
  • phil: yeesh... okay, but I should figure this out; on it
  • brad: ideally it should just be flash the userspace app and run the tools, but, YMMV
  • amit: I'm happy to help...
  • phil: focus on IPC :)
  • hudson: I've also done USB testing, can help

https://github.com/tock/tock/issues/2320

  • phil: useful to check in on?
  • leon: proposal didn't get much backlash? seems last discussion deemed reasonable?
  • amit: that's roughly my takeaway as well
  • phil: okay.

Flash / Flash HIL

  • brad: many periodic issues with the Flash HIL; been a lingering issue for ~years now
  • brad: one group really wants to see it change / re-write; another camp of "it works, why change"
  • brad: would be good a plan/vision of some kind here
  • amit: let's put this on the agenda for next week when Alistair is back to join
  • amit: might just be a matter of consensus building; maybe different interfaces for on-chip/off-chip, etc
  • phil: yeah, things were designed for one use case, but other use cases have arrived
  • phil: thought there was actually a good discussion

Exit [terminate vs restart]

  • phil: in the syscall discussions, exit semantics came up
  • phil: kernel can do whatever it wants w.r.t. restarting or terminating you...
  • phil: so are these syscalls hints or directives -- what promises does the kernel make to app?
  • brad: good point; one idea might be to document not as "these are the two versions of exit", rather "you get so many bits of exit-with-value, and the way we've programmed the kernel is that it takes than number under advisement; 0 means app wanted to exit so there's no benefit to restarting the app; non-zero means something went awry, maybe should try restarting"
  • phil: where does this number go?
  • brad: two places -> 1) the printout when a board crashes on exit, 2) debug information for the process (via process console)
  • phil: this conflates two things: something wrong happened with, please restart me
  • amit: mental model is maybe systemd-like, some services should keep running (i.e. webserver that restart) while others are one-off (cron-like things?)
  • phil: Agree with the idea of there are applications that do and don't want to restart. One example was a migration app (e.g. a db update "app")
  • phil: The concern is really the conflation of return codes
  • amit: we have a bunch of space for these things -- why not both? have register space for exit reason and restart policy
  • phil: absolutely, we have the space
  • phil: didn't see a reason before, but these are good points
  • brad: two values seems reasonable to me
  • brad: but agree, can't make promises, this is request semantics
  • phil: right, that made me nervous at first, but that's really what most OSes provide.. so here we are

Fin.