> 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!
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.