Re: [RFC PATCH] Adding RTC device (work in progress)

[Sergey Bugaev]

On Fri, Nov 8, 2024 at 3:26 AM Zhaoming Luo <zhaoming1357@qq.com> wrote:
> The rest of the stuff
> is mainly about filling codes into the server-side functions; it may
> require some time as I haven't had any experience of writing drivers.

Me neither :) But, perhaps the following would be somewhat useful.

The osdev wiki has articles about RTC [0] and CMOS [1]; looks like one
can access them pretty easily with 'in'/'out' on ports 0x70 and 0x71.
The SerenityOS driver [2][3][4] seems to match the osdev articles
well; it must have been written using them as a reference.

[0]: https://wiki.osdev.org/RTC
[1]: https://wiki.osdev.org/CMOS
[2]: 
https://github.com/SerenityOS/serenity/blob/master/Kernel/Arch/x86_64/Time/RTC.cpp
[3]: 
https://github.com/SerenityOS/serenity/blob/master/Kernel/Arch/x86_64/RTC.cpp
[4]: 
https://github.com/SerenityOS/serenity/blob/master/Kernel/Arch/x86_64/CMOS.cpp

To enable your process to use 'in' & 'out', you have to call ioperm
(), I believe — which on the Hurd is implemented via the
i386_io_perm_create and i386_io_perm_modify gnumach RPCs; this
requires having access to the device master port, i.e. being root. You
should then be able to use inb/outb functions from sys/io.h (or
perhaps their _p versions?)

This seems to be the QEMU-side implementation:
https://gitlab.com/qemu-project/qemu/-/blob/master/hw/rtc/mc146818rtc.c

All of this is specific to x86 and/or "PC" (or rather: "Motorola
MC146818"?); the Linux doc [5] talks about the "old PC/AT-Compatible
driver: /dev/rtc" and "new portable “RTC Class” drivers: /dev/rtcN".
Perhaps this should be taken into consideration? It's completely fine
to only support the x86/PC RTC for now, but let's make sure we end up
with a design that allows us to support other platforms (ARM, RISC-V)
in the future.

[5] https://docs.kernel.org/admin-guide/rtc.html

I know that RTC can be configured to either represent local time, or
in UTC. MS Windows prefers the former, GNU/Linux (or rather systemd?)
prefers the latter [6]. Would it maybe make sense for the driver to
have an --option to *pretend* the RTC stores UTC time when it's
actually storing local time, transparently converting the time on
read/write? The driver would learn the local timezone the same way all
processes do (tzset?).

[6]: https://wiki.archlinux.org/title/System_time

Sergey