Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Oxide on My Wrist: Hubris on PineTime was the best worst idea

artemis.sh

Post reply on HN
Print view View original

31–40 of 51 posts

Re: Oxide on My Wrist: Hubris on PineTime was the best worst idea

#31

Post by ctz »

bcantrill wrote: post #26
zozbot234 wrote: post #4

Earlier quoted context omitted.

Thing is, it's not even clear that their added elements are all that sensible. If you're always running trusted tasks on your embedded hardware, what do you need the MPU for? Even in principle, it can only save you a bounds check. And if you start running outside code, then the clear privilege separation in Tock between trusted "Capsules" and other "Tasks" starts looking plenty attractive. Even OP notes that this MPU…

Other folks have mentioned this, but it's important to understand the limitations of Rust with respect to safety. In particular: every stack operation is -- at some level -- an unsafe operation as it operates without a bounds check. This isn't Rust's fault per se; non-segmented architectures don't have an architecturally defined way to know the stack base. As a result, even an entirely safe Rust program can make an i…

> non-segmented architectures don't have an architecturally defined way to know the stack base

ARMv8-M does have stack limit registers, which do precisely this. Being a much simpler mechanism than the MPU, they are quicker to switch than the entire MPU state when switching tasks.

Re: Oxide on My Wrist: Hubris on PineTime was the best worst idea

#33

Post by bcantrill »

ctz wrote: post #31
bcantrill wrote: post #26

Earlier quoted context omitted.

Other folks have mentioned this, but it's important to understand the limitations of Rust with respect to safety. In particular: every stack operation is -- at some level -- an unsafe operation as it operates without a bounds check. This isn't Rust's fault per se; non-segmented architectures don't have an architecturally defined way to know the stack base. As a result, even an entirely safe Rust program can make an i…

> non-segmented architectures don't have an architecturally defined way to know the stack base ARMv8-M does have stack limit registers, which do precisely this. Being a much simpler mechanism than the MPU, they are quicker to switch than the entire MPU state when switching tasks.

Yes, true -- it's more accurate to say "architectures traditionally don't have a way to know the stack base." Certainly, having an architecturally-defined way to know the base of the stack is/would be really really helpful, and would allow stack overflow to be at once less dangerous and much more debuggable!

Re: Oxide on My Wrist: Hubris on PineTime was the best worst idea

#34

Post by hemogloben »

protoman3000 wrote: post #10

The github repo of hubris [0] is very nice, as they immediately tell you where what is, e.g. drv/ contains drivers, a mix of simple driver lib crates and fully-fledged server bin crates. Current convention is that drv/SYSTEM-DEVICE is the driver for DEVICE on SYSTEM (where SYSTEM is usually an SoC name), whereas drv/SYSTEM-DEVICE-server is the server bin crate. Why does nobody do this in their readmes normally? They…

I've never understood why github shows the first line of the most recent commit for files / folders next to their name instead of the first line of any README.md file inside the folder.

Even on projects that I'm actively working on, the most recent commit of a folder gives me no useful information, whereas if I could edit the README.md I could atleast add a description of each folder so that new users could understand the directory structure better.

Re: Oxide on My Wrist: Hubris on PineTime was the best worst idea

#35

Post by bcantrill »

zozbot234 wrote: post #28
bcantrill wrote: post #26

Earlier quoted context omitted.

Other folks have mentioned this, but it's important to understand the limitations of Rust with respect to safety. In particular: every stack operation is -- at some level -- an unsafe operation as it operates without a bounds check. This isn't Rust's fault per se; non-segmented architectures don't have an architecturally defined way to know the stack base. As a result, even an entirely safe Rust program can make an i…

> This isn't Rust's fault per se; non-segmented architectures don't have an architecturally defined way to know the stack base. Bounding stack usage is of course a whole-program concern, but that ought to be feasible when building for embedded, where external "plugin" components are unlikely and there's no inherent need for true separate compilation. (Arguably, in such cases even the need for an actual "stack" struct…

But to get back to your original question: you can see why the state of things today necessitates the use of the MPU, even for Rust?

Re: Oxide on My Wrist: Hubris on PineTime was the best worst idea

#36

Post by athenot »

hemogloben wrote: post #34
protoman3000 wrote: post #10

The github repo of hubris [0] is very nice, as they immediately tell you where what is, e.g. drv/ contains drivers, a mix of simple driver lib crates and fully-fledged server bin crates. Current convention is that drv/SYSTEM-DEVICE is the driver for DEVICE on SYSTEM (where SYSTEM is usually an SoC name), whereas drv/SYSTEM-DEVICE-server is the server bin crate. Why does nobody do this in their readmes normally? They…

I've never understood why github shows the first line of the most recent commit for files / folders next to their name instead of the first line of any README.md file inside the folder. Even on projects that I'm actively working on, the most recent commit of a folder gives me no useful information, whereas if I could edit the README.md I could atleast add a description of each folder so that new users could understan…

Same thought; I would love if there were a way to toggle between "latest commit message" and "first line of documentation for the file", depending on whether it's a familiar project or a new one I'm browsing.

Re: Oxide on My Wrist: Hubris on PineTime was the best worst idea

#37

Post by a9h74j »

> Compare these two videos of writing a solid block of color to the screen, first through the SPI task, and second with direct SPI hardware access:

I wonder if the performance difference could, in some applications, create a preference for processors with enough SPI ports to dedicate one per peripheral (no chip select required). Not only no shared bus (as in I2C), but no shared SPI-task.

Re: Oxide on My Wrist: Hubris on PineTime was the best worst idea

#39

Post by ComputerGuru »

Can anyone clue me in on the status of async/await in hubris? I have some HAL code that both really needs and uses async (or callbacks) to work and currently just use my own homebrew WFE/WFI wakers (with a fixed, known a priori number of tasks) but it would be nice to switch to something more elegant and less brittle.

(Context: async/await-based per-task loop to facilitate background LoRa send/receive while other tasks can continue to operate (DMA, SPI, etc) independently, with the overall loop shutting the primary Cortex core down when processing is completed/while waiting for events/updates.)

The last I checked, hubris was strictly synchronous and I didn't get the sense that the interaction between tasks was architectured in such a way that would facilitate low-power designs for battery-powered devices.

Re: Oxide on My Wrist: Hubris on PineTime was the best worst idea

#40

Post by steveklabnik »

ComputerGuru wrote: post #39

Can anyone clue me in on the status of async/await in hubris? I have some HAL code that both really needs and uses async (or callbacks) to work and currently just use my own homebrew WFE/WFI wakers (with a fixed, known a priori number of tasks) but it would be nice to switch to something more elegant and less brittle. (Context: async/await-based per-task loop to facilitate background LoRa send/receive while other tas…

We don't use async in hubris, so there is no async/await. Hubris is 99.99999% synchronous.

For more: https://hubris.oxide.computer/reference/#_why_synchronous

(Basically, this probably hasn't changed since you looked at it, but for anyone else who hasn't seen it yet...)

> shutting the primary Cortex core down

We don't have mainline support for multicore systems, and there's a big ? in there, design-wise. So yes, you are right to recognize that that is the current state of things.

Post reply on HN