linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Guangyu Kang (Shanghai)" <GuangyuKang@viatech.com.cn>
To: "'Elladan'" <elladan@eskimo.com>
Cc: "'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>
Subject: RE: Help please: DVD ROM read difficulty
Date: Fri, 7 Mar 2003 15:49:27 +0800	[thread overview]
Message-ID: <C373923C3B6ED611874200010250D52E155E23@exchsh01.viatech.com.cn> (raw)

Elladan, thank you for your reply :)

>I've had to try junk like:
>
>	while true ; do kill -9 $stupid_process ; done
>
>.. just to get something to die when it's reading bad media.
>A quick way around this tends to be to hit the eject button on the CD
>drive itself - it will cause the driver to abort the read quickly when
>it sees that the drive is empty.

You are quite right, this is exactly what I got. Maybe the cache mechanism
will do some check
before send request to the ide-cd driver, and it will abort at that point,
since there is an path
for the failure report.

While to me, this issue is some how player quality related, I have to deal
with it. And you said that
the error handling is not good at all, I think its hopeless for me to hack
into fs and cache. Now I have
an idea in mind to implement an ioctl() set to do this.
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 reauest. 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.

Ugly though, this should be some how easier.

Any comment and advice is welcomed!

             reply	other threads:[~2003-03-07  7:39 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-07  7:49 Guangyu Kang (Shanghai) [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-03-09  5:48 Help please: DVD ROM read difficulty Guangyu Kang (Shanghai)
2003-03-07  2:14 Guangyu Kang (Shanghai)
2003-03-07  6:54 ` Elladan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=C373923C3B6ED611874200010250D52E155E23@exchsh01.viatech.com.cn \
    --to=guangyukang@viatech.com.cn \
    --cc=elladan@eskimo.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).