+that will be using this driver. See the code at the end of this document.
+
+(The original /dev/rtc driver was written by Paul Gortmaker.)
+
+
+ New portable "RTC Class" drivers: /dev/rtcN
+ --------------------------------------------
+
+Because Linux supports many non-ACPI and non-PC platforms, some of which
+have more than one RTC style clock, it needed a more portable solution
+than expecting a single battery-backed MC146818 clone on every system.
+Accordingly, a new "RTC Class" framework has been defined. It offers
+three different userspace interfaces:
+
+ * /dev/rtcN ... much the same as the older /dev/rtc interface
+
+ * /sys/class/rtc/rtcN ... sysfs attributes support readonly
+ access to some RTC attributes.
+
+ * /proc/driver/rtc ... the first RTC (rtc0) may expose itself
+ using a procfs interface. More information is (currently) shown
+ here than through sysfs.
+
+The RTC Class framework supports a wide variety of RTCs, ranging from those
+integrated into embeddable system-on-chip (SOC) processors to discrete chips
+using I2C, SPI, or some other bus to communicate with the host CPU. There's
+even support for PC-style RTCs ... including the features exposed on newer PCs
+through ACPI.
+
+The new framework also removes the "one RTC per system" restriction. For
+example, maybe the low-power battery-backed RTC is a discrete I2C chip, but
+a high functionality RTC is integrated into the SOC. That system might read
+the system clock from the discrete RTC, but use the integrated one for all
+other tasks, because of its greater functionality.
+
+The ioctl() calls supported by /dev/rtc are also supported by the RTC class
+framework. However, because the chips and systems are not standardized,
+some PC/AT functionality might not be provided. And in the same way, some
+newer features -- including those enabled by ACPI -- are exposed by the
+RTC class framework, but can't be supported by the older driver.
+
+ * RTC_RD_TIME, RTC_SET_TIME ... every RTC supports at least reading
+ time, returning the result as a Gregorian calendar date and 24 hour
+ wall clock time. To be most useful, this time may also be updated.
+
+ * RTC_AIE_ON, RTC_AIE_OFF, RTC_ALM_SET, RTC_ALM_READ ... when the RTC
+ is connected to an IRQ line, it can often issue an alarm IRQ up to
+ 24 hours in the future.
+
+ * RTC_WKALM_SET, RTC_WKALM_READ ... RTCs that can issue alarms beyond
+ the next 24 hours use a slightly more powerful API, which supports
+ setting the longer alarm time and enabling its IRQ using a single
+ request (using the same model as EFI firmware).
+
+ * RTC_UIE_ON, RTC_UIE_OFF ... if the RTC offers IRQs, it probably
+ also offers update IRQs whenever the "seconds" counter changes.
+ If needed, the RTC framework can emulate this mechanism.
+
+ * RTC_PIE_ON, RTC_PIE_OFF, RTC_IRQP_SET, RTC_IRQP_READ ... another
+ feature often accessible with an IRQ line is a periodic IRQ, issued
+ at settable frequencies (usually 2^N Hz).
+
+In many cases, the RTC alarm can be a system wake event, used to force
+Linux out of a low power sleep state (or hibernation) back to a fully
+operational state. For example, a system could enter a deep power saving
+state until it's time to execute some scheduled tasks.