RE: Help please: DVD ROM read difficulty

[Guangyu Kang]

Thanks, and I forget to cc every one :-P
I just come up from the lower layer, I suspected that it's the ide/ide-cd's
flaw.
If the upper layer is fine, there should be some thing due to interface. 
To me, ide just seems fine, ide-cd have some trival issue on error handling,
I don't think they are so bad that can be called flaw. While do abort on
this or that error case is just all I can do in ide-cd.

Now I do not have any more point - I will try what I said, just wait for my
result, hehe.

On Sun, Mar 09, 2003 at 11:35:53AM +0800, Guangyu Kang (Shanghai) wrote:
> >> Looks like:
> >> CDROM_IOCTL_LOCK
> >> CDROM_IOCTRL_REALTIME_LOGICBLOCK_READ
> >> The lock will make the driver refuse any more open to the driver, thus
> the
> >> driver can concdern on read
> >> operation from my ioctl while not the request. If some one opened the
> driver
> >> already, lock will fail.
> >> The read will be an re-organize of request handler code, adding more
> >> straight-forward error handling,
> >> which will get data from drive and copy it to user. Without the cache
> layer,
> >> in player case,
> >> better performance may be the additional gain.
> 
> >Maybe what you need here is a variant of O_DIRECT ?
> -J
> 
> 
> 
> Yeah should be it. Now I got another advice to use RAW device feature.
> 
> My old idea of the two ioctl will work like the stand alone DVD player set
> which put its output directly into a TV. I mean there will be a single
> buffer managed by player, seeking will done by player itself, and the dvd
> rom driver works much more straight forward. 
> 
> And I took a look at the raw device code yesterday, it looks like an
> re-organize of request processing code in ide-cd.c, I mean it works in a
> loop that send the request one by one, there will not be too much request
> that causes long delay. I think the cache mechanism will send a lot of
> requests and thus driver must do a lot of 10 second device time out.
> 
> RAW read still will not return failt easily, and it has its own seeking
> mechanism. This is troublesome.  You know libdvdread I'm using will do its
> own UDF handling and seeking, etc. and then read the device /dev/hdc.
> 
> I think a combine of modified ide-cd.c that abort on HARDWARE_ERROR and
RAW
> and read/seek check will be sufficient.

I dunno, I really don't know enough about the IDE driver and the block
layer to help much here.  :-(

I tried to read the IDE/Block/ISO9660 layers once to figure out why it
sometimes crashes and puts processes into permanent D state, and the
block and fs layers were nice and sensible, but as soon as I hit the IDE
driver I just gave up.  Ugh.  More special cases than code.

People in the mailist list don't seem all that interested, though, but
they're the one with a clue...

-J