3 ms·

> Unlike a signal-handler, it never alters the control-flow of the code you read on the page...Code you write in a task executes as written, or fails. Nothing

> Unlike a signal-handler, it never alters the control-flow of the code you read on the page...Code you write in a task executes as written, or fails. Nothing in the system will arbitrarily alter your program's control-flow from what appears on the page...Now, when phrased like that, it seems weird to have to say it out loud, like, don't all programmers pretty much assume that the code that they write runs the way they wrote it? And to that I say yes, we absolutely do, and that assumption is often wrong, and leads to common classes of bugs, starting with data races and moving on up. Wow, this is really insightful

panick21_ 5y ago
It really puts the task into the hands of the programmer. The way the it works (if I understand correctly from the docks) the programmer of a task needs to make sure it checks for notifications when it want to and controls that process. This gives the programmers some rope to hang themselves with, but on the other hand you don't get shot by the OS when you don't want to.
- brundolf 5y ago
  Yeah. Though importantly, all of these tasks are (as I understand it) being designed and developed cohesively, by a small team under a single roof. We're not talking about random userspace applications in a general-purpose OS; new tasks can't even be started and stopped at runtime, they're laid out at build time. I think that's why this explicit and cooperative model can work.
  - panick21_ 5y ago
    I would assume as the ecosystem grows 'standard' task will develop that will see a lot of reuse between different people using this OS. But I agree critically you build deploy this as a complete system even if many of the tasks are not inhouse. You still test the complete system.
- bcantrill 5y ago
  If you want a very concrete example to hang your hat on: making the I2C driver interrupt driven was a snap -- and importantly, can easily be done from a library, where the caller merely provides functions to call to enable a specified interrupt and to synchronously wait for interrupts.[0] [0] https://github.com/oxidecomputer/hubris/blob/01b5af3d54348bad1ad0d64cc17abde58fa61979/drv/stm32h7-i2c/src/lib.rs#L439 https://github.com/oxidecomputer/hubris/blob/01b5af3d54348ba...
  - elcritch 5y ago
    Looks interesting! Though I noticed the bit about the Konami code. The terminology is great, but alas it feels like I've run into as many i2c devices that break the i2c protocol as follow it. Ahem, I'd recommend avoiding Infineon I2C devices to keep your sanity. ;) Reading the code, is it correct to say the ISR will timeout if the device doesn't respond? It's nice the driver returns the state of the bus locking in the error `Err(drv_i2c_api::ResponseCode::BusLocked);`. Makes me curious how you're doing that. I need to find timeout watch the video.
    - bcantrill 5y ago
      Noted on the Infineon devices! ;) Yes, it will timeout if the device doesn't respond, thanks to the timeout logic in the STM32H7's I2C block.[0] If the block didn't have that logic, Hubris would still make it relatively easy to do that, though, as one would just perform the closed receive for the interrupt or a timer notification. (An example of a closed receive on a timer can be found at [1].) [0] https://github.com/oxidecomputer/hubris/blob/01b5af3d54348bad1ad0d64cc17abde58fa61979/drv/stm32h7-i2c/src/lib.rs#L249-L274 https://github.com/oxidecomputer/hubris/blob/01b5af3d54348ba... [1] https://github.com/oxidecomputer/hubris/blob/01b5af3d54348bad1ad0d64cc17abde58fa61979/sys/userlib/src/hl.rs#L626-L645 https://github.com/oxidecomputer/hubris/blob/01b5af3d54348ba...

panick21_ 5y ago

It really puts the task into the hands of the programmer. The way the it works (if I understand correctly from the docks) the programmer of a task needs to make sure it checks for notifications when it want to and controls that process. This gives the programmers some rope to hang themselves with, but on the other hand you don't get shot by the OS when you don't want to.

brundolf 5y ago
Yeah. Though importantly, all of these tasks are (as I understand it) being designed and developed cohesively, by a small team under a single roof. We're not talking about random userspace applications in a general-purpose OS; new tasks can't even be started and stopped at runtime, they're laid out at build time. I think that's why this explicit and cooperative model can work.
- panick21_ 5y ago
  I would assume as the ecosystem grows 'standard' task will develop that will see a lot of reuse between different people using this OS. But I agree critically you build deploy this as a complete system even if many of the tasks are not inhouse. You still test the complete system.
bcantrill 5y ago
If you want a very concrete example to hang your hat on: making the I2C driver interrupt driven was a snap -- and importantly, can easily be done from a library, where the caller merely provides functions to call to enable a specified interrupt and to synchronously wait for interrupts.[0] [0] https://github.com/oxidecomputer/hubris/blob/01b5af3d54348bad1ad0d64cc17abde58fa61979/drv/stm32h7-i2c/src/lib.rs#L439 https://github.com/oxidecomputer/hubris/blob/01b5af3d54348ba...
- elcritch 5y ago
  Looks interesting! Though I noticed the bit about the Konami code. The terminology is great, but alas it feels like I've run into as many i2c devices that break the i2c protocol as follow it. Ahem, I'd recommend avoiding Infineon I2C devices to keep your sanity. ;) Reading the code, is it correct to say the ISR will timeout if the device doesn't respond? It's nice the driver returns the state of the bus locking in the error `Err(drv_i2c_api::ResponseCode::BusLocked);`. Makes me curious how you're doing that. I need to find timeout watch the video.
  - bcantrill 5y ago
    Noted on the Infineon devices! ;) Yes, it will timeout if the device doesn't respond, thanks to the timeout logic in the STM32H7's I2C block.[0] If the block didn't have that logic, Hubris would still make it relatively easy to do that, though, as one would just perform the closed receive for the interrupt or a timer notification. (An example of a closed receive on a timer can be found at [1].) [0] https://github.com/oxidecomputer/hubris/blob/01b5af3d54348bad1ad0d64cc17abde58fa61979/drv/stm32h7-i2c/src/lib.rs#L249-L274 https://github.com/oxidecomputer/hubris/blob/01b5af3d54348ba... [1] https://github.com/oxidecomputer/hubris/blob/01b5af3d54348bad1ad0d64cc17abde58fa61979/sys/userlib/src/hl.rs#L626-L645 https://github.com/oxidecomputer/hubris/blob/01b5af3d54348ba...