[lkml]   [2003]   [May]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [BK PATCHES] add ata scsi driver
Bartlomiej Zolnierkiewicz wrote:
> 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.

SATA2 is really 100% different from PATA in all respects except for the
ATA commands themselves being sent down the pipe. Doing that inside
drivers/ide really means two driver cores at that point.

Sharing code is definitely an option, though!
Why do you think I named it "libata"? :)

Another SATA wrinkle: the phy layer.

SATA, like network cards, has an underlying connection layer. The host
connects to the device. Your link state may be up or down. This is
easily mapped to SCSI semantics (initiator connection to target). Much
more code if writing from scratch.

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

You misunderstand.

drivers/ide -- uses function pointers HWIF->outb, etc. inside a static
taskfile-submit function. The TF submit functions statically order each
HWIF->outb() call, and you cannot change that order from the low-level

my driver -- uses separate taskfile-submit functions for different hardware.

My method directly uses outb(), writel(), or whatever is necessary. It
allows one to use __writel() and barriers to optimize as needed, or to
support special cache coherency needs. Further, for SATA and some
advanced PATA controllers, my method allows one to use a completely
alien and new taskfile submission method. For example, building SATA2
FIS's as an array of u32's, and then queueing that FIS onto a DMA ring.
The existing drivers/ide code is nowhere close to that.

Putting it into drivers/ide language, my driver adds a
HWIF->do_flagged_taskfile hook, and eliminates the HWIF->outb hooks.
Turns ~13 hook calls into one, from looking at flagged_taskfile.

And FWIW, I would not state "measureably faster" unless I actually
benchmarked it. :) It's a pittance in the grand scheme of things,
since you're inevitably limited by device speed, but lower CPU usage is
something nobody complains about...

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

Oh agreed. But scsi is pretty much there now (it's in testing in a BK
tree), and we're darn close to 2.6.0.

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

Yes, almost always.

The problem with polling is that it chews up CPU if you're not careful,
starving out other processes. I'm careful :)

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

As you can see from the discussion, I think a new driver best serves the
future of SATA2 as well as today's SATA. So I'm not gonna bother... I
have a driver that works.

If you're interested in working the problem, the result of booting ICH5
SATA in drivers/ide is a hang at
hdX: attached to ide-disk driver

Nothing happens after that. sysrq doesn't work, so my assumption was
that the bus was locked up.

>>So, I conclude: faster, smaller, and better future direction. IMO, of
>>course :)
> And right now ugly and incomplete.
> IMO, of course ;-).

Incomplete? Kinda sorta. SATAPI isn't here yet, so all it needs is
more fine-grained error handling. I call it 100% stable now, though.

Ugly? Compared to drivers/ide? I actually have a lot of admiration and
respect for the PATA knowledge embedded in drivers/ide. But I would
never call it pretty :)


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:35    [W:0.159 / U:1.116 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site