* Re: [PATCH] fix req->cmd == INT cases
[not found] ` <4679072C.2010604@panasas.com>
@ 2007-06-20 12:22 ` Christoph Hellwig
2007-06-20 12:24 ` Jens Axboe
0 siblings, 1 reply; 5+ messages in thread
From: Christoph Hellwig @ 2007-06-20 12:22 UTC (permalink / raw)
To: Boaz Harrosh; +Cc: Jens Axboe, linux-scsi, linux-kernel
On Wed, Jun 20, 2007 at 01:53:32PM +0300, Boaz Harrosh wrote:
> Jens Axboe wrote:
> >
> > If you look at most of the code, it's inside ifdef debug statements or
> > comments most of them. So I don't think you can base any removal
> > suggestion on that.
> >
> > The patch itself looks fine though, if you send one that isn't mangled
> > I'll apply it to the 2.6.23 branch.
> >
> Sorry new Thunderbird Installation. I forgot it does that.
>
> - I have unearthed very old bugs in stale drivers that still
> used request->cmd as a READ|WRITE int
> - This patch is maybe a proof that these drivers have not been
> used for a long time. Should they be removed completely?
>
> Drivers that currently do not work for sure:
> drivers/acorn/block/fd1772.c
> drivers/acorn/block/mfmhd.c
Afaik these are old arm26 driver, and that port is dead and should
probably be removed from the tree entirely.
> 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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] fix req->cmd == INT cases
2007-06-20 12:22 ` [PATCH] fix req->cmd == INT cases Christoph Hellwig
@ 2007-06-20 12:24 ` Jens Axboe
2007-06-20 12:26 ` Christoph Hellwig
2007-06-20 21:16 ` Rene Herman
0 siblings, 2 replies; 5+ messages in thread
From: Jens Axboe @ 2007-06-20 12:24 UTC (permalink / raw)
To: Christoph Hellwig, Boaz Harrosh, linux-scsi, linux-kernel
On Wed, Jun 20 2007, Christoph Hellwig wrote:
> On Wed, Jun 20, 2007 at 01:53:32PM +0300, Boaz Harrosh wrote:
> > Jens Axboe wrote:
> > >
> > > If you look at most of the code, it's inside ifdef debug statements or
> > > comments most of them. So I don't think you can base any removal
> > > suggestion on that.
> > >
> > > The patch itself looks fine though, if you send one that isn't mangled
> > > I'll apply it to the 2.6.23 branch.
> > >
> > Sorry new Thunderbird Installation. I forgot it does that.
> >
> > - I have unearthed very old bugs in stale drivers that still
> > used request->cmd as a READ|WRITE int
> > - This patch is maybe a proof that these drivers have not been
> > used for a long time. Should they be removed completely?
> >
> > Drivers that currently do not work for sure:
> > drivers/acorn/block/fd1772.c
> > drivers/acorn/block/mfmhd.c
>
> Afaik these are old arm26 driver, and that port is dead and should
> probably be removed from the tree entirely.
>
> > 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? mitsumi support is being reworked, that can get reintroduced once
the driver is in a stable state.
--
Jens Axboe
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] fix req->cmd == INT cases
2007-06-20 12:24 ` Jens Axboe
@ 2007-06-20 12:26 ` Christoph Hellwig
2007-06-20 21:16 ` Rene Herman
1 sibling, 0 replies; 5+ messages in thread
From: Christoph Hellwig @ 2007-06-20 12:26 UTC (permalink / raw)
To: Jens Axboe; +Cc: Christoph Hellwig, Boaz Harrosh, linux-scsi, linux-kernel
On Wed, Jun 20, 2007 at 02:24:09PM +0200, Jens Axboe wrote:
> > 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? mitsumi support is being reworked, that can get reintroduced once
> the driver is in a stable state.
Yeah - the new mitsumi doesn't share anything with the old one anyway.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] fix req->cmd == INT cases
2007-06-20 12:24 ` Jens Axboe
2007-06-20 12:26 ` Christoph Hellwig
@ 2007-06-20 21:16 ` Rene Herman
2007-06-21 6:32 ` Jens Axboe
1 sibling, 1 reply; 5+ messages in thread
From: Rene Herman @ 2007-06-20 21:16 UTC (permalink / raw)
To: Jens Axboe; +Cc: Christoph Hellwig, Boaz Harrosh, linux-scsi, linux-kernel
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] fix req->cmd == INT cases
2007-06-20 21:16 ` Rene Herman
@ 2007-06-21 6:32 ` Jens Axboe
0 siblings, 0 replies; 5+ messages in thread
From: Jens Axboe @ 2007-06-21 6:32 UTC (permalink / raw)
To: Rene Herman; +Cc: Christoph Hellwig, Boaz Harrosh, linux-scsi, linux-kernel
On Wed, Jun 20 2007, Rene Herman wrote:
> 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.
Sure, a working clean driver would always be allowed in. I'll remove the
legacy drivers in 2.6.23.
> 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...
Heh, that's pretty scary!
> >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
Yeah I know, I will get around to it eventually.
--
Jens Axboe
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2007-06-21 6:33 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <4677FD50.2090803@panasas.com>
[not found] ` <20070619171610.GH18863@kernel.dk>
[not found] ` <4679072C.2010604@panasas.com>
2007-06-20 12:22 ` [PATCH] fix req->cmd == INT cases Christoph Hellwig
2007-06-20 12:24 ` Jens Axboe
2007-06-20 12:26 ` Christoph Hellwig
2007-06-20 21:16 ` Rene Herman
2007-06-21 6:32 ` Jens Axboe
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).