Andy >>>... User-land application should stick to >>>whatever kernel expect them to stick to. Period. me >> In principle, i agree. But what about things like adjtimex() not working Andy > And who says that failure to adjtimex is not caused by a kernel bug? > ... > then you better adhere to interface specification.
My only excuse is that the SCSI kernel interface is a bit far from my usual playgrounds. My intended interface is described in man cdrecord or man growisofs. (At least i knew that i was quite lost.) > And once you mentioned adjtimex, I'd guess that you have 2.4 kernel and 2.4.21 > it's patched with "variable HZ" patch. Here is the "root of the mess" > you've been looking for. That sounds like a valuable hint for getting smarter on this topic. Thanks once again. > ... Everything > else is your kernel vendor trying to be "cool" rather than making sure > they don't screw it up for you:-) Yeah - sigh. I got my real-world reasons to stick with that vendor. But they got no reason to love me, either. So it's a draw. Much better than anything which i could achieve with Microsoft. :)) Joerg > 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 :-( That is working fine here. Speed messages and my realworld clocks correlate. Time is tricky. With my last system, burning CDs caused the clock to slow down by 1 minute per CD. Therefore i had to use adjtimex at all. Now this new one gains several seconds per day. Reason not found yet. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
