> >> Well besides the fact that your program is nonportable and relies on a > >> Linux proprietary interface introduced recently: > > >The next line read "this is proof-of-concept code." The sole reason for > >deploying Linux proprietary interface is for faster coding [and > >distribution]. The idea is rather to have people try it out with their > >drives in order to figure out if IMMED works "already" (at the very > >least it does with mine Ricoh OEM drive). > > Well, I see no reason why your code should be faster to write than portable > code.
It was faster to write for *me*. Is it so hard to imagine? > If you are talking about the IMMED bit, well I was experimenting with it > 4 years before you send your mail...... It's commonly referred to that most drives manufactured [rather designed, right?] after 98 are MMC-3 compliant..... > With get confiruration, it seems that you don't know that this is a MMC-3 only > command. I am not sure whether a single CD writer supports it TOSHIBA SD-R1102 (another drive I have) does... > OK, DVD writers and something called DVD+RW although not DVD from current > standards support it. Writing portable software that supports many drives is > different from writing a demonstrator for a single drive type. I'd say "those first," not "a single." > >So why don't we make it optional with -immed command line option and > >[optionally] disable it [the -immed option] on drives not identifying > >themselves as ATAPI in reply to "GET CONFIGURATION(46h)" [assuming that > >such not responding in appropriate manner are not MMC-3 compliant]? > > Nowyou got it: only MMC-3 drives support get configuration. This is a small > minority of drives. For all times ever since? A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
