On Tuesday, June 17, 2008 at 12:11:20 -0700, David Brownell wrote: > I don't like the idea of the *kernel* trying to impose that much of > a one-size-fits-all model on RTCs But... The kernel is already imposing one mostly fixed view of the RTC to applications. This view hides some gory details, which is rather good. This view permits uniform operations on various RTCs, which is also good. And this view filters out any nice feature not fitting the abstraction (like the hundredths of second), which is a pity. I'd tend to think to the restart delay as being a gory detail, worth to be hidden. And hiding it would help uniform operations. > that's a way to accumulate in-kernel bloat, not minimize it. Not at all: We're talking about setting a value to 50 instead of setting it to 0. Not a single line more or less. >> This twice better "accuracy" probably justifies the inclusion of such >> restart delay by hardware designers 20 years ago. > There are other solutions, which is why that 20-year-old notion hasn't > caught on for newer discrete RTCs Which other solutions? Or rather: Which other hardware solutions are still available and effective above the ioctl(/dev/rtc) interface? I mean: as example Uwe's Digi RTC has a readable/writable hundredths of second value, and it can trigger update interrupts each hundredth. If those pearls were available to applications, then: - hwclock --hctosys would take less than 10 ms (faster boots!!) - hwclock --systohc would take less than 130 ms - hwclock operations would have their usual sub-second and sub-hundredth full precision - busybox would have only 10 ms of maximum error, and still an instant execution But that's not possible: /dev/rtc mandates one second granularity, and 1 Hz update interrupts. In this granular context, which other solutions can minimize the setting error of busybox? >> The user of another RTC may get perfect results with the >> --correct=+0.5 option > Better IMO to have the util-linux-ng RTC config file have an option > like that, and set it to 500 milliseconds on PC hardware. A command > line option could override that, or any default. Too good an idea to not be already implemented somewhere :-) hwclock 2.33 stores the given --correct value as a float into the 1st item of the 5th line of /etc/adjtime. Further calls reuse the same correction, until another --correct option is given. However, I tend to think about --correct as a handy but temporary workaround, not as the definitive solution to the restart delay problem. I may be wrong, but to me the adaptation to various RTC behaviours should be automatic, transparent to users. Fixed by other means. And users should have the --correct option fully available (always zero based on all RTCs) to fight against the constant part of the usual small machine-dependant setting errors, like the around -2 ms bias of PCs. > Note that your proposal was to model such a delay in the drivers. > I hope I showed why that's not good. Yes: So far I'm convinced that imposing a half-second in the /dev/rtc abstract, and mimic one when there is none, would be hard or impossible to do in all drivers. But I'm not convinced that the half-second restart delay is a weird quirky misfeature. Well to the contrary, I now think it is a good thing in a second granular world, because of its quite handy error rounding effect, and especially because of the embedded/busybox argument. I'm also not convinced that the driver of one given RTC has any reason to not mimic a half-second (if it's quick and easy). It will then benefit from the 3 positive points of my initial pros list, and from this 4th: be more busybox-friendly. No foreseable drawback. > But there could be a need for such modeling in the infrastructure glue What do you mean? I can see you make distinctions between kernel, driver, and glue. I fear to not be familiar enough with kernel internals to follow such nuances well... Alain. -- 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
