Hi, David Weisgerber wrote: > So I will create a patch which adds such a switch to growisofs Andy Polyakov wrote earlier: > There is a way to open image without O_DIRECT and without modifying > source code: growisofs -Z /dev/cdrom=/dev/fd/0 < image.iso. Ta-dah...
In my role as a frontend programmer for growisofs i would first try whether "Ta-dah" is a viable workaround. > Otherwise I would need to > distribute a patched version of growisofs with turbojet... If you rely on a growisofs novelty then you have to urge the users to install newest dvd+rw-tools. "Ta-dah" - if possible - would allow a much better decoupling of your software and the system installed tools. Back to my role as backend programmer: David Weisgerber wrote: > In most cases it is a good idea to rely on the fact that the one who has > implemented caching in the operating system knew what he is doing. Yes and no. I assume that the kernel people are smarter than me in respect to overall system issues. But i assume that i am more informed than them when it comes to the particular use cases of my programs. me: > "David and Andy, i believe that there are reasons" Er, that should have been "Bill and Andy". Some cranial short circuit with "David" and "Davidsen". I apologize. In general i lean(ed) more towards the opinion of David Weisgerber. But one argument of Bill and Andy is very strong: Why involve the caching in cases where one knows that it will be of no benefit ? The main reason why i not flatly introduce in libburn an option to use O_DIRECT is the system dependency. Andy disabled it in growisofs for Linux 2.4 kernels. (Another reason why i never noticed any effect o my older computers.) Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
