Re: ide-scsi is deprecated for cd burning! Use ide-cd and give dev=/dev/hdXas device

[Bill Davidsen]

Valdis.Kletnieks@xxxxxx wrote:
> On Fri, 18 Feb 2005 15:23:44 EST, Bill Davidsen said:
>
>
> > I'll try to build a truth table for this, I'm now working with some 
> > non-iso data sets, so I'm a bit more interested. I would expect read() 
> > to only try to read one sector, so I'll just do a quick and dirty to get 
> > the size from the command line, seek and read.
> >
> > I haven't had a problem using dd to date, as long as I know how long the 
> > data set was, but I'll try to have results tonight.
>
>
> The problem is that often you don't know exactly how long the data set is
> (think "backup burned to CD/RW") - there's a *lot* of code that does stuff
> like
>
> 	while (actual=read(fd,buffer,65536) > 0) {
> 		...
> 	}
>
> with the realistic expectation that the last read might return less than 64k,
> in which case 'actual' will tell us how much was read.  Instead, we just get
> an error on the read.
>
> Note that 'dd' does this - that's why you get messages like '12343+1 blocks read'.
> We *really* want to get to a point where 'dd' will work *without* having to
> tell it a 'bs=' and 'count=' to get the size right....

I think I already had a pretty good grasp on that, in my previous post 
on this I noted: "The last time I looked at this, the issue was that the 
user software did a large read and the ide-cd didn't properly return a 
small data block with no error, but rather returned an error with no 
data. If you get the size of the ISO image, you can read that with any 
program which doesn't try to read MORE than that."

It sounds as if (a) the problem with ide-cd is going to get fixed, and 
(b) ide-scsi may not remain depreciated. A win-win if I ever saw one.

--
   -bill davidsen (davidsen@xxxxxxx)
"The secret to procrastination is to put things off until the
 last possible moment - but no longer"  -me
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/