public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: Ben Collins <ben.collins@ubuntu.com>
Cc: Linus Torvalds <torvalds@osdl.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH rc6] block: Fix CDROMEJECT to work in more cases
Date: Wed, 21 Dec 2005 08:04:04 +0100	[thread overview]
Message-ID: <20051221070404.GV3734@suse.de> (raw)
In-Reply-To: <1135115219.16754.41.camel@localhost.localdomain>

On Tue, Dec 20 2005, Ben Collins wrote:
> On Tue, 2005-12-20 at 21:53 +0100, Jens Axboe wrote:
> > On Tue, Dec 20 2005, Ben Collins wrote:
> > > However, I don't see the issue with using READ. We know this isn't a
> > > write operation, we are sending a single command with no data. I know
> > > you say reads are precious, but 3 requests for something that isn't
> > > going to happen very often doesn't seem that bad.
> > 
> > It's not a READ either!
> > 
> > Yes I'm being stubborn, but my point stands. I'm not changing something
> > that is perfectly valid, "just because". If it finds a bug (you
> > mentioned ide-cd, I still want the details on that when you have the
> > time), then it's all for the better since it would bite us for other
> > paths as well.
> > 
> > In summary - it's not a bug, it doesn't need fixing.
> 
> Then for the sake of nothing other than consistency, fix sg_io() to use
> WRITE for cases where data_len==0? That means it would use READ only
> when data is actually being read, and WRITE for everything else,
> including all zero data commands (sounds sort of backwards to me,
> though). Currently, it does the opposite. The main point being that
> sending these commands from SG_IO ioctl should be the same as they get
> sent from CDROMEJECT ioctl.
> 
> I wonder how many bugs will pop up if you do that. Probably less now
> that the scsi code is fixed.

We can try that for the next -rc1, but I don't think it will find a lot
of bugs to be honest. I'm really surprised that the SCSI bug was there,
it's one of those pretty basic things that should have been caught
sooner. Perhaps with more coverage, we can try changing sg_io() after
2.6.15 release.

-- 
Jens Axboe


      reply	other threads:[~2005-12-21  7:02 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-19 19:50 [PATCH rc6] block: Fix CDROMEJECT to work in more cases Ben Collins
2005-12-20 17:34 ` Linus Torvalds
2005-12-20 17:49   ` Jens Axboe
2005-12-20 18:08     ` Linus Torvalds
2005-12-20 18:38       ` Jens Axboe
2005-12-20 18:53         ` Linus Torvalds
2005-12-20 19:08           ` Jens Axboe
2005-12-20 20:38       ` Ben Collins
2005-12-20 20:53         ` Jens Axboe
2005-12-20 21:46           ` Ben Collins
2005-12-21  7:04             ` Jens Axboe [this message]

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=20051221070404.GV3734@suse.de \
    --to=axboe@suse.de \
    --cc=ben.collins@ubuntu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.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