... User-land application should stick to whatever kernel expect them to stick to. Period.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.
And who says that failure to adjtimex is not caused by a kernel bug? 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.