Re: Questions about cdrtools-2.01a33
>From: Andy Polyakov <appro@fy.chalmers.se>
>> In principle, i agree. But what about things like adjtimex() not working at
>> all when i combined man-page information with userland HZ ?
>> If i don't want to live with a clock which is a bit too fast then i have to
>> tweak the local rules so they allow me to slow that clock down from time to
>> time. I try to keep those tweaks encapsulated and strictly local.
The Linux kernel "engineers" completely missiundetand the time problem :-(
The assumption that the sys clock is more accurate than the battery clock
is inherently wrong. If you run xntp to make the sys clock accurate, the
needed actions are taken in xntp.
Trying to manage the battry clock from sysclock creates big big problems, e.g.
jumping time on a notebook. Note that a sleeping notebook or ATA PIO mode ...
causes interrupts to get lost......
The correct method can be seen on Solaris: sysclock checks every few seconds
whether the battery clock if there is more then 1 second off from sysclock and
corrects sysclock. If there is a jump > 30 minutes assume battery clock
failure and correct battery clock.
I did get many reports from angry people who tell me that cdrecords write speed
computations are wrong on Linux although it was the kernel' clock :-(
>And who says that failure to adjtimex is not caused by a kernel bug?
See above: Linux time "mamnagement" is a pure desaster.
>Once again. Even though there is no guarantee that kernel treats value
>correctly (because of a kernel bug), *formally* this can't be used as an
>excuse for application to disregard interface specification and start
>feeding kernel with upscaled [or downscaled] values. As for
>*informality* of real-life situations and desire to make it work even in
>non-perfect environment. I'd say that you would absolutely need
>*reliable* and preferably non-intrusive way to detect that the bug is in
>fact present at run-time(!) and povide an *extra* workaround path. If
>you don't have such way or don't want to provide extra workaround path,
>then you better adhere to interface specification.
>And once you mentioned adjtimex, I'd guess that you have 2.4 kernel and
>it's patched with "variable HZ" patch. Here is the "root of the mess"
>you've been looking for. Note that "official" Linux 2.4 kernels, those
>avaialable in source code from ftp.kernel.org, don't offer this
>"configurable HZ" option and HZ of 100 works correctly. "Official" 2.6
>kernels scale USER_HZ internally to ensure correct behaviour. Everything
>else is your kernel vendor trying to be "cool" rather than making sure
>they don't screw it up for you:-) A.
A decently designed kernel does not define interfaces that send time
related user data to the kernel that depends on the value of HZ but uses
absolute time values.
A decently designed kernel that includes ingertfaces that transfer
time values to userland that depend on HZ, offers user land definitions for HZ
like this:
#define HZ ((clock_t)_sysconf(_SC_CLK_TCK))
Linux failes for both :-(
The problem is that many uneducated people (people who did never learn what an
interface is) do define Linux kernel interfaces. The top name to mention
is Linus T. :-(
As a rule ot Thumb: If you ever created a user level interface that was a
mistake and this interface has been around and documented for a long time,
you need to find a way out that does not break existing programs (in special
if the new versions are still working on old kernels).
Linux Kernel design is ravaged by thinkering people....
Jörg
--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni) If you don't have iso-8859-1
schilling@fokus.fraunhofer.de (work) chars I am J"org Schilling
URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
Reply to: