public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: Jamie Lokier <jamie@shareable.org>
Cc: Stuart Hayes <Stuart_Hayes@dell.com>, linux-kernel@vger.kernel.org
Subject: Re: PATCH (for 2.6.3-rc1) for cdrom driver dvd_read_struct
Date: Wed, 11 Feb 2004 13:09:37 +0100	[thread overview]
Message-ID: <20040211120937.GA19047@suse.de> (raw)
In-Reply-To: <20040211115123.GB15127@mail.shareable.org>

On Wed, Feb 11 2004, Jamie Lokier wrote:
> Jens Axboe wrote:
> > On Tue, Feb 10 2004, Stuart Hayes wrote:
> > > The attached patch will make the "dvd_read_struct" function in cdrom.c 
> > > check that the DVD drive can currently do the DVD read structure command 
> > > before sending the command to the drive.  It does this by checking the 
> > > "dvd read" feature using the "get configuration" command.
> > > 
> > > Currently, cdrom.c only checks that the drive is a DVD drive before 
> > > allowing the dvd read structure command to go to the drive--it does not 
> > > make sure that the DVD drive has a DVD in it.  Without this patch, if CD 
> > > medium is in a DVD drive, and the DVD_READ_STRUCT ioctl is used, the drive
> > > will spew an ugly "illegal request" error (magicdev does this).
> > 
> > I'm rather anxious about applying anything like this, in my experience
> > it's much much safer to simply let the command fail. I don't see
> > anything technically wrong with your approach, I'd just like it tested
> > on 100 different dvd drives :)
> 
> Meaning that you don't trust the DVD media test to return true on all
> drives when and only when there's DVD media currently in there?
> 
> If that's your logic, it follows that userspace programs shouldn't
> trust the DVD media test either - they should always call
> DVD_READ_STRUCT if they would like to treat DVDs differently to CDs.
> 
> So, can you add a flag to the request meaning "if this
> DVD_READ_STRUCT request fails with illegal request, don't log it"?

There's the generic cgc->quiet bit for this very purpose. However,
thinking about this particular issue some more,  the feature check
really ought to work for all cases. So I think it's worth a shot
applying the patch as-is. I don't see any better solutions.

-- 
Jens Axboe


  reply	other threads:[~2004-02-11 12:09 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-10 16:46 PATCH (for 2.6.3-rc1) for cdrom driver dvd_read_struct Stuart Hayes
2004-02-10 17:12 ` Jens Axboe
2004-02-11 11:51   ` Jamie Lokier
2004-02-11 12:09     ` Jens Axboe [this message]
  -- strict thread matches above, loose matches on Subject: below --
2004-02-10 18:06 Stuart_Hayes
2004-02-10 18:27 ` Matt Domsch
2004-02-10 23:26   ` Adam Kropelin
2004-02-11 12:10     ` Jens Axboe

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=20040211120937.GA19047@suse.de \
    --to=axboe@suse.de \
    --cc=Stuart_Hayes@dell.com \
    --cc=jamie@shareable.org \
    --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