I'm not entirely sure we can trust the CMOS RTC alarm state getting propagated through to the /proc/driver/rtc interface on all hardware. Perhaps one should use the rtc ioctl() interface to set/get RTC status. There is some sketchy documentation in the kernel source tree under Documentation/rtc.txt
Specifically, perhaps probing the RTC alarm date using the RTC_ALM_READ ioctl() may fetch a date that shows that the alarm has fired or not.
The documentation illustrates how to read the current alarm setting using:
/* Read the current alarm settings */
retval = ioctl(fd, RTC_ALM_READ, &rtc_tm);
if (retval == -1) { perror("RTC_ALM_READ ioctl"); exit(errno);
}
fprintf(stderr, "Alarm time now set to %02d:%02d:%02d.\n", rtc_tm.tm_hour, rtc_tm.tm_min, rtc_tm.tm_sec);
Maybe this is a more reliable method rather than checking the state via /proc/driver/rtc
I'm not entirely sure we can trust the CMOS RTC alarm state getting propagated through to the /proc/driver/rtc interface on all hardware. Perhaps one should use the rtc ioctl() interface to set/get RTC status. There is some sketchy documentation in the kernel source tree under Documentation/ rtc.txt
Specifically, perhaps probing the RTC alarm date using the RTC_ALM_READ ioctl() may fetch a date that shows that the alarm has fired or not.
The documentation illustrates how to read the current alarm setting using:
/* Read the current alarm settings */
perror( "RTC_ALM_ READ ioctl");
exit( errno);
retval = ioctl(fd, RTC_ALM_READ, &rtc_tm);
if (retval == -1) {
}
Maybe this is a more reliable method rather than checking the state via /proc/driver/rtc