> 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/