Messages in this thread | | | Date | Mon, 26 May 2003 12:32:45 +0200 (MET DST) | From | Bartlomiej Zolnierkiewicz <> | Subject | Re: [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/
| |