On Fri, Nov 8, 2024 at 3:26 AM Zhaoming Luo <zhaoming1...@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
