On Monday 16 June 2008, Alain Guibert wrote: > Hello David, gentlemen, > > On Wednesday, April 30, 2008 at 0:50:50 -0700, David Brownell wrote: > > > One issue is a mechanism that's specific to the PC/AT clone RTCs: > > waiting for "exactly" 1/2 second after the clock rolls over before > > setting the clock, since those RTCs wait a half second. If someone > > has time to work such issues: that 1/2 second delay [...] should not > > be required, since most RTCs don't have those PC/AT semantics. > > ... > > For other RTCs, shouldn't the device driver mimic such half second > restart delay? IMO, no. But there should probably be a way to export a list of hardware "features" (and misfeatures) of which that would be one, or at least to identify the RTC hardware through /dev operations. Think of it this way: look at drivers/rtc and look at how many have that hardware limitation, vs how many don't. One ... versus at least three dozen. (Where I assume that the RTCs I don't happen to have looked at in detail follow the pattern.) Updating three dozen drivers to match misfeatures of one would be an odd game to *chose* to play... > ... so > far I can see only advantages: > > - ioctl(RTC_SET_TIME) behaviour consistent across different RTCs. That's probably worth thinking about. Seems to me one of the main issues here is that one version of "hwclock" wrongly thinks it will always add an undocumented a half-second delay. > - All(?) RTC-setting apps work well out-of-the-box unmodified. Busybox "hwclock" sure doesn't. Most of those drivers/rtc/rtc-*.c files are used on embedded hardware; busybox comes first. Does anything other than the util-linux(-ng) "hwclock" know about this quirk of the PC RTC? > - Applications timestamping the first tick following RTC_SET_TIME for > verification will have to wait half a second only, instead of a full > second. I'm trying to understand what, other than hwclock or a replacement for it, would ever do that. > I could imagine no potential drawback in setting HSEC=50, nor find any > practical advantage in doing otherwise. What do you think about this? Drawbacks of adding that requirement to drivers: needing to modify and retest over three dozen drivers, adding a hard-to-test behavioral quirk. Advantages to not doing so: no need to re-test several dozen drivers on hardware that may not be readily testable, saner design for the RTC infrastructure and its ongoing evolution. ... that said, I have no objection to finding a better solution for this half-second delay. One that doesn't involve changing dozens of drivers. - Dave -- To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
