Re: Questions about cdrtools-2.01a33
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
Reply to: