> If you can solve a problem in userspace, why bother force-fitting it into the kernel? Chumby probably could have figured out a way to make the STM32 show up as an actual /dev/rtc0 device…but what would the advantage have been over the scripts they wrote? None.
For something like the Chumby, where userland is basically fixed and doesn't have a half dozen distros building on top of it, I agree. But if this were commodity hardware that Debian, Ubuntu, Arch, Mint, etc wanted to pull in support for, the extra time spent making /dev/rtc0 would mean the distros don't have to implement their own non-standard implementation of setting the clock.
Author here. That's very much a fair point. I was thinking more from the perspective of firmware developers maintaining fixed userlands when I wrote that.
It would definitely be an interesting challenge to figure out how to multiplex the UART between being a normal UART and accesses from an RTC driver in order to allow it to be a real RTC!
Yeah, I was thinking this too. The benefit of making the STM32 look like a real RTC to the kernel would mean that userspace would Just Work when it came to saving and restoring the time. The kernel would restore it on boot using its normal mechanism, and the 'hwclock' command would actually work properly, like someone unfamiliar with this particular quirk of the hardware would expect.
Likely this was a bit easier and faster to implement from the perspective of the Chumby folks who were building the system. But I've seen enough weird non-standard things done on embedded Linux systems (and have unfortunately been involved in maintaining one or two of them) to believe that this sort of crap is annoying, and wish developers at the manufacturer would do things in ways that the platform expects.
Interesting, thanks for mentioning CUSE. If I’m understanding it correctly, it seems like it would be a perfect solution for this. Allows leaving the logic in userspace which is much easier to deal with (filesystem access, sharing the UART) but would still show up as an RTC device. I may need to play further with this!
Amazing work, thanks for sharing it! It warms my heart to see someone still hacking on the device after...13 years. It was a crazy idea to open source it back then, but seeing it pop up in the wild long after the company went away is some validation towards the idea that an empowered community has tenacious staying power.
We couldn't figure out how to monetize it, but that's alright with me; not all returns on investment are measurable in dollars.
I got one of the soft, ball-like chumbys when they came out. Really, really amazing design and packaging :) I tried to love it as much as it radiated good vibes but sadly from the very beginning it was kind of janky and at the time the usefulness was not that clear to me. Too bad the cheerfulness of such hardware got lost along the way.
I think the Chumby came out just a little too late. Great idea, but like so many things the post-iPhone-smartphone began to fill all the roles that those things filled
I was thinking about the brief life of the dedicated flash video cameras. They were more capable than phones of the era, but they couldn’t share on their own.
The Chumby also came out early enough that it had to rely on Flash Lite [1] for authoring content. This severely limited the audience that could build content for it; if it had came out a bit later, with better hardware, it could have potentially been used to display HTML content, and things might have gone differently.
I was thinking about the brief life of the dedicated flash video cameras. They were more capable than phones of the era, but they couldn’t share on their own.
Those are still used in environments where that is a feature, not a bug.
A few years ago I wrote[0] about a similar approach on an RTC-less system (a Raspberry 3B+) by utilising systemd's clock-epoch to set time across reboots to be "reasonably close enough" for DNS-over-TLS and chrony's NTS to take over, and avoid large time jumps being observed by daemons.
To that last point: reading this file is one of the very first things systemd does after being started right in main, so time is set before any services are brought up. Whereas time for the OP isn't set until the `500datetime` service is loaded.
To be clear, my init script is named S00datetime, not 500datetime. It's actually the very first one that runs from rcS. So the date is restored very, very early in the boot process before pretty much everything else.
For something like the Chumby, where userland is basically fixed and doesn't have a half dozen distros building on top of it, I agree. But if this were commodity hardware that Debian, Ubuntu, Arch, Mint, etc wanted to pull in support for, the extra time spent making /dev/rtc0 would mean the distros don't have to implement their own non-standard implementation of setting the clock.