As it is a property of the mc146818, it should be constant across all
arch that use drivers/char/rtc.c
Sparc uses drivers/sbus/char/rtc.c which is for Mostek 4802. No comment
mentions a 500ms delay there - or in the file arch/sparc/kernel/time.c
*However* the test for the 500ms is still in the latter (in set_rtc_mmss).
> (ii) instead of waiting, isn't it much easier to redefine
> what it means to access rtc?
Yes, and possibly what I had in mind some 5 years ago (as I'm sure I would
have looked at set_rtc_mmss at the time...)
> (If you read a certain value then on average you are halfway
> that second; if you write a certain value you are precisely
> halfway that second. Maybe no delays are needed or desired.)
Calling it a "feature" is clearly easier - no code patched, no flag day
for new behaviour, and no need for user space utils to have to do a
uname() to see if a 500ms delay is implemented. The more I think about
it, the better I like this option.
Paul.
--- drivers/char/rtc.c~ Sat Jan 6 05:40:24 2001
+++ drivers/char/rtc.c Mon Jan 8 04:57:59 2001
@@ -20,6 +20,14 @@
* interrupts since the last read in the remaining high bytes. The
* /dev/rtc interface can also be used with the select(2) call.
*
+ * The driver also supports ioctls for reading and setting the
+ * date/time stored in the RTC in a SMP safe fashion (used by
+ * the [hw]clock program). Note that for the mc146818 RTC, the
+ * second for which the RTC is set is half over, by definition.
+ * Thus your application may require a 0.5 second delay before
+ * calling this driver to set the RTC time if exact synchronization
+ * is desired.
+ *
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/