這篇開始基本上是進入持續分析有哪些未完善的部份需要進行補足。
依照這幾次的bootlog的部份分析，Alpine OpenRC-init的modloop以及hwclock/swclock兩個target是起不來的，且有錯誤顯示settimeofday是壞的。
modloop如名稱所示，是Alpine自己的世界觀中，如果有module需要runtime啟動、則從一個loopback去mount起來尋找，對於我目前的porting而言，我不太介意，但說後者會是我比較在意的部份。

簡單來說，syslog要啟動時，需要有正確的wall clock才有意義，OpenRC這邊給的第一條路是去呼叫userspace程式： hwclock來作wall clock設定；如果fail的時候，會啟動OpenRC自己的builtin：
https://github.com/OpenRC/openrc/blob/master/src/rc/swclock.c
其實也很簡單、就透過settimeofday這個POSIX規定的user API去設時間。

快速看過後，發現躺著這組東西在busybox的mailing list上：
http://lists.busybox.net/pipermail/busybox/2021-March/088583.html

籠統說來，這是一個musl-libc跟busybox造成的共同慘案。對於RISC-V32這種新世代的32平台來說，time_64t是基礎人權狀態，所以很多以前相關32/64相容的過渡性syscall直接是不存在的。但是目前musl-libc的compat32機制，是直接把settimeofday強制導向32版本：

int __settimeofday_time32() __asm__("settimeofday");

所以我的確有兩件事情要修正，第一件是要去修正musl的 arch/riscv32/bits/syscall.h.in，把 170 號的legacy settimeofday 槓掉、加上404號的 clock_settime64，但是這樣改完並不夠，因為目前整個使用邏輯是錯的，修正方向有兩條、一條是要去把compat32修好，另一條是apply那條patch、要busybox自己去call 404號syscall就好。

因為hwclock、也就是去找busybox做事是OpenRC的優先選擇，我決定這邊先apply busybox的部份。等下一篇開始驗證這套打通後，Alpine的OpenRC hwclock會不會正常運作起來。