linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rene Herman <rene.herman@gmail.com>
To: Jens Axboe <jens.axboe@oracle.com>
Cc: Christoph Hellwig <hch@infradead.org>,
	Boaz Harrosh <bharrosh@panasas.com>,
	linux-scsi <linux-scsi@vger.kernel.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] fix req->cmd == INT cases
Date: Wed, 20 Jun 2007 23:16:56 +0200	[thread overview]
Message-ID: <46799948.8000106@gmail.com> (raw)
In-Reply-To: <20070620122409.GU18863@kernel.dk>

On 06/20/2007 02:24 PM, Jens Axboe wrote:

> On Wed, Jun 20 2007, Christoph Hellwig wrote:
>> On Wed, Jun 20, 2007 at 01:53:32PM +0300, Boaz Harrosh wrote:

>>>  drivers/cdrom/aztcd.c
>>>  drivers/cdrom/cm206.c
>>>  drivers/cdrom/gscd.c
>>>  drivers/cdrom/mcdx.c
>>>  drivers/cdrom/optcd.c
>>>  drivers/cdrom/sjcd.c
>>> 
>> These are old cdrom drivers that are broken in various ways and
>> probably should be killed off aswell.
> 
> I agree (with both sentiments), would anyone mind if I just killed them
> off?

I wouldn't. As far as I'm concerned everything in drivers/cdrom except 
viocd.c and cdrom.c itself can go, assuming I'll be allowed to bring back 
support for the legacy cdrom types I'd still like to have supported -- in 
the first place mitsumi (mcdx), panasonic (sbpcd) and sony (cdu31a) and 
perhaps at some point other types if/when I happen across the hardware.

The old drivers serve as a source of hardware information but at least mcdx 
was broken in so many ways that it only did so at the source level. When I 
wanted to check throughput with the old driver I actually had to go back as 
far as 2.0.34 to find a working driver (the old mcd.c, already removed since 
2.6.10). 2.0.34 sources are available from kernel.org, and 2.6.22 sources 
even from my local machine...

> mitsumi support is being reworked, that can get reintroduced once the
> driver is in a stable state.

... which, by the way, is still waiting on comment from anyone with a clue 
as to why it makes the machine go boom (easily repeatable when using CFQ, 
not or not easily when using AS):

http://lkml.org/lkml/2007/6/4/50

Rene.

  parent reply	other threads:[~2007-06-20 21:16 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-19 15:59 [PATCH] fix req->cmd == INT cases Boaz Harrosh
2007-06-19 17:16 ` Jens Axboe
2007-06-20 10:53   ` Boaz Harrosh
2007-06-20 10:59     ` Jens Axboe
2007-06-20 11:31       ` Boaz Harrosh
2007-06-20 12:22     ` Christoph Hellwig
2007-06-20 12:24       ` Jens Axboe
2007-06-20 12:26         ` Christoph Hellwig
2007-06-20 21:16         ` Rene Herman [this message]
2007-06-21  6:32           ` 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=46799948.8000106@gmail.com \
    --to=rene.herman@gmail.com \
    --cc=bharrosh@panasas.com \
    --cc=hch@infradead.org \
    --cc=jens.axboe@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@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).