[lkml]   [2002]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [2.5] DAC960
On Sun, Sep 15 2002, Daniel Phillips wrote:
> On Tuesday 10 September 2002 08:20, Jens Axboe wrote:
> > On Tue, Sep 10 2002, Samium Gromoff wrote:
> > > Hello folks, i`m looking at the DAC960 driver and i have
> > > realised its implemented at the block layer, bypassing SCSI.
> > >
> > > So given i have some motivation to have a working 2.5 DAC960
> > > driver (i have one, being my only controller)
> > > i`m kinda pondering the matter.
> > >
> > > Questions:
> > > 1. Whether we need the thing to be ported to SCSI
> > > layer, as opposed to leaving it being a generic block device? (i suppose yes)
> >
> > No
> A somewhat curt reply, it could be seen as a brush-off. I believe the
> whole story goes something like this: the scsi system is a festering
> sore on the whole and eventually needs to be rationalized. But until
> that happens, we should basically just keep nursing along the various
> drivers that should be using a generic interface, until there really
> is a generic interface around worth putting in the effort to port to.

Please, the scsi sub system is not a 'festering sore'. Have you even
taken a decent look at it, or just spreading the usual "I heard SCSI
dizzed somwhere" fud? Sure there's room for improvement, 2.5 has in fact
already gotten quite a lot. It's not perfect and there's still stuff
that can be cleaned up, but that doesn't mean it's crap.

> Linus indicated at the Kernel Summit that he'd like to see a
> cleaned-up scsi midlayer used as framework for *all* disk IO,
> including IDE. Obviously, what with IDE transitions and whatnot, we
> are far from being ready to attempt that, so see "nursing along"
> above. There's no longer any chance that a generic disk midlayer is
> going to happen in this cycle, as far as I can see. Still, anybody
> who is interested would do well by studing the issues, and fixing
> broken drivers certainly qualifies as a way to come up to speed.

First of all, I believe Linus' plan is to push more functionality into
the block layer. Generic functionality. And in fact a lot of has already
happened there, but one does need to pay attention to that sort of thing
instead of just assuming spouting fud. Examples:

- queue merge and dma mappings. this is all generic block/bio
functionality now. please compare scsi_merge.c between 2.4 and
2.5, if you care to.

- highmem bounceless operation also added the possibilty to do
isa bouncing generically in 2.5. this is also gone from scsi.

- request tagging. 2.5 has a generic implementation, scsi
transition is not complete though.

that's just off the top of my head.

So where am I going with this? I said "don't bother" to the question of
studying SCSI code, and I stand by that 100%. It would be an absolute
_waste of time_ if the goal is to make dac960 work in 2.5. I believe why
should be pretty obvious now.

Daniel, your (seen before) 'clarification' posts are not.

> > > 2. Which 2.5 SCSI driver should i use as a start of learning?
> >
> > Don't bother
> Ah, a little harsh. I'd say: study the DAC960 driver, study the
> scsi midlayer, and study the new bio interface. That's what I'm
> doing.

My advise is: take a look at the transition of other drivers, forget
scsi. Study of bio goes hand in hand with learning from transition of
other drivers. And note that a reasonable update of dac960 should remove
3x as much code as it adds, at least.

I can only note that so far there has been a lot of talk about dac960
and updating it, and that's about it. Talk/code ratio is very very low,
I'm tempted to just do the update myself. Might even safe some time.

Jens Axboe

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:28    [W:0.097 / U:20.088 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site