lkml.org 
[lkml]   [2003]   [May]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [BK PATCHES] add ata scsi driver

On Mon, 26 May 2003, Jeff Garzik wrote:

> Linus Torvalds wrote:
> > On Mon, 26 May 2003, Jeff Garzik wrote:
> >
> >>Just to echo some comments I said in private, this driver is _not_
> >>a replacement for drivers/ide. This is not, and has never been,
> >>the intention. In fact, I need drivers/ide's continued existence,
> >>so that I may have fewer boundaries on future development.
> >
> >
> > Just out of interest, is there any _point_ to this driver? I can
> > appreciate the approach, but I'd like to know if it does anything (at all)
> > better than the native IDE driver? Faster? Anything?
>
>
> Direction: SATA is much more suited to SCSI, because otherwise you wind
> up re-creating all the queueing and error handling mess that SCSI
> already does for you. The SATA2 host controllers coming out soon do
> full host-side TCQ, not the dain-bramaged ATA TCQ bus-release stuff.
> Doing SATA2 devel in drivers/ide will essentially be re-creating the
> SCSI mid-layer.

And now you are recreating ATA in SCSI ;-).

Don't get me wrong: I like idea very much, but why you can't
share common code between drivers/ide and your ATA-SCSI.

> Modularity: drivers/ide has come a long way. It needed to be turned
> "inside out", and that's what Alan did. But there's still a lot of code
> that needs to be factored out/about, before hotplugging and device model
> stuff is sane.

Its getting close.

> Legacy-free: Because I don't have to worry about legacy host
> controllers, I can ignore limitations drivers/ide cannot. In
> drivers/ide, each host IO (PIO/MMIO) is done via function pointer. If
> your arch has a mach_vec, more function pointers. Mine does direct
> calls to the asm/io.h functions in faster. So, ATA command submission
> is measureably faster.

I think it is simply wrong, you should use function pointers.
You can have ie. two PCI hosts, one using PIO and one using MMIO.

"measureably faster", I doubt.
IO operations are REALLY slow when compared to CPU cycles.

> sysfs: James and co are putting time into getting scsi sysfs right. I
> would rather ride their coattails, and have my driver Just Work with
> sysfs and the driver model.

No big deal here, ATA will get it too.

> PIO data transfer is faster and more scheduler-friendly, since it polls
> from a kernel thread.

CPU polling is faster than IRQs?

> And for specifically Intel SATA, drivers/ide flat out doesn't work (even
> though it claims to).

So fix it ;-).

> So, I conclude: faster, smaller, and better future direction. IMO, of
> course :)

And right now ugly and incomplete.
IMO, of course ;-).

Regards,
--
Bartlomiej

> Jeff
>
>
>
> (the following is somewhat comparing apples to oranges, but I like doing
> it nonetheless)

social engineering removed


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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