All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.