add ata scsi driver

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.

Even though ATAPI support doesn't exist and error handling is primitive, this driver has been extensively tested locally and I feel is ready for a full and public kernel developer assault :)

James ok'd sending this... I'll be sending "un-hack scsi headers" patch through him via his scsi-misc-2.5 tree.

Linus, please do a

bk pull bk://kernel.bkbits.net/jgarzik/scsi-2.5

Others may download the patch from

ftp://ftp.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.5/2.5.69-bk18-scsi1.patch.bz2

This will update the following files:

 drivers/scsi/Kconfig    |   27 
 drivers/scsi/Makefile   |    1 
 drivers/scsi/ata_piix.c |  322 ++++++
 drivers/scsi/libata.c   | 2247 ++++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/ata.h     |  485 ++++++++++
 5 files changed, 3082 insertions(+)

through these ChangeSets:

<[email protected]> (03/05/26 1.1357)
[scsi ata] make PATA config option actually do something useful

<[email protected]> (03/05/26 1.1356)
[scsi ata] include hacks, b/c scsi headers not in include/linux

<[email protected]> (03/05/26 1.1355)
[scsi] add ATA driver

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?

Linus

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.

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.

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.

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.

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

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

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

Jeff

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

bash-2.05b$ wc -l drivers/scsi/libata.c drivers/scsi/ata_piix.c include/linux/ata.h
2247 drivers/scsi/libata.c

    322 drivers/scsi/ata_piix.c
    485 include/linux/ata.h

3054 total

bash-2.05b$ wc -l drivers/ide/*.[ch] drivers/ide/pci/piix.[ch]
3418 drivers/ide/ide-cd.c

    733 drivers/ide/ide-cd.h
     71 drivers/ide/ide-default.c
   1841 drivers/ide/ide-disk.c
   1145 drivers/ide/ide-dma.c
   2090 drivers/ide/ide-floppy.c
    135 drivers/ide/ide-geometry.c
   1330 drivers/ide/ide-io.c
   1322 drivers/ide/ide-iops.c
    437 drivers/ide/ide-lib.c
     97 drivers/ide/ide-pnp.c
   1466 drivers/ide/ide-probe.c
    930 drivers/ide/ide-proc.c
   6330 drivers/ide/ide-tape.c
   2006 drivers/ide/ide-taskfile.c
    798 drivers/ide/ide-tcq.c
    281 drivers/ide/ide-timing.h
   2539 drivers/ide/ide.c
     41 drivers/ide/ide_modes.h
    899 drivers/ide/setup-pci.c
    840 drivers/ide/pci/piix.c
    317 drivers/ide/pci/piix.h

29066 total

As a FWIW, this driver is mainly intended as a Serial ATA driver.

It just happens to do PATA by coincedence (i.e. because it makes devel easier for me).

For example, current Intel SATA is "PATA, but without the timing junk."

I think with SATA + drivers/ide, you reach a point of diminishing returns versus amount of time spent on mid-layer coding.

Jeff

I think that's a valid approach, and just have a special driver for SATA. That's not the part I worry about.

The part I worry about is the SCSI layer itself, and also potential user confusion.

Linus

You're still at a point of diminishing returns for a native driver too.

ATAPI support would be a pain. Can't use drivers/ide/* nor ide-scsi.

Userland support is nonexistent, and users would have start using yet another set of tools to deal with their disks, instead of the existing [scsi] ones.

Device model, power management, hotplugging are all handled or in-the-works for scsi, and they are exactly what SATA needs. I would have to recreate all that handling from scratch.

I think you're missing how much code and pain is actually saved by using the scsi layer... like I mentioned in the last message, long-term, these issues can (and should) be solved by moving some of this stuff out of the scsi layer into the block layer, creating an overall desirable flattening effect of all code involved.

I think this can only benefit the scsi layer and continue its trend of becoming more lightweight and lib'ified.

WRT user confusion, I agree: that's why PATA is a config option. I would prefer people think "SATA? use my driver. PATA? use drivers/ide"

Andre suggested that I might support PCI PATA controllers in my driver "officially", but I think user confusion and transition issues rule out that, for non-hackers.

Jeff

No, because for a block-queue native driver there would be one huge
advantage: making sure the native queueing is brought up to be a fully used interface.

Originally, native queueing was all there was, and all drivers interfaced directly to it. The IDE and SCSI layers ended up being used largely because they allowed drivers to use a global naming scheme, not because they were "better". In fact, in many ways they were a lot worse than the native queues, but then they had some other infrastructure that did help.

My bet is that most of that infrastructure today is just not worth it.

That's not true. The command set is already exported, so that even things like packet commands can be sent (that's how you write CD-RW under 2.5.x, and it's the _generic_ layer that does all the command queueing).

That, btw, i show you should do the ATA transport thing. Even SCSI devices can get the commands fed that way. It's neither ATA nor SCSI, it's a "packet interface for the generic queue".

The only remaining piece of the puzzle (from a user land perspective) ends up being the mapping from major/minor -> queue. That used to be a _huge_ issue, and the main reason you couldn't write a SCSI driver outside the SCSI layer, for example (but look at DAC960 - it decided to do so _anyway_, even if it meant being ostracised and put on a separate major).

But that should be much less of an issue now, since our queue mapping is a lot more flexible these days.

Clue-in-time: if hotplugging doesn't work on a native level, it won't work on a SCSI level either. So that _cannot_ be a real issue.

Device model stuff and power management all comes from other areas, and have little to do with SCSI.

Linus

[...]

Correct, but precisely by saying that, you're missing something.

The SCSI midlayer provides infrastructure I need -- which is not specific to SCSI at all.

Device registration, host registration, major/minor sub-allocation, device model, power management, command queueing features, command timeout, error handling thread, userland command submission interface (a la taskfile ioctl or SG_IO)... all these are possible via the generic block layer -- but the generic block layer does not directly provide these facilities. Each subsystem (ide, scsi, ...) has to provide bits on top of that to make it usable. Each native block driver must re-create these for its own subsystem.

All those "little bits" add up to code I have to write, for a native driver, which I don't have to write for SCSI.

IF you are willing to sign off on a generic /dev/disk (bus agnostic), then I am interested. That allows me to code up the above stuff ONCE, and not see others do the same work when they write a native blk driver (or avoid this work, by using SCSI like I do now). Otherwise. I'm writing all those little bits YET AGAIN, duplicating stuff scsi already does.

Taking that to a concrete level, that basically means more helpers at the native block level.

Given that I have always agreed a native block driver is the best eventual method, what's stopping me? Time:

If /dev/disk is a non-starter for 2.6, the best route is to take my SCSI driver and evolve it over time to be a native block driver. Not start with a native block driver. That gives us a SATA framework now, and SCSI can disappear eventually. #include <linux_is_usable_not_pie_in_sky_theory.h>

(re-arranged msg a bit)

I agree the capabilities are there for packet interface, but one still has to define the userland interface. Yes, I know about SG_IO. It's: somewhat SCSI-specific, and sub-optimal. Think back to December 2001, when you described a packet interface using read(2) and write(2). Basically SG_IO, but better and without scsi specifics.

The mapping part is easy, IMO. I would just have the "generic infrastructure" export chrdrvs for each queue I manage, using the interface you described in December 2001. sysfs can then describe the {major+minor | CIDR | whatever}-to-queue mapping.

For example, when /dev/disk device registration occurs at runtime, the /dev/disk infrastructure would make a new chrdrv appear.

Anyway, stepping back to the larger issue of "userland tools", I'm not just talking about a taskfile I/O interface. I'm talking about all the little distro tools for IDE and SCSI, like /usr/bin/scsi_unique_id or /sbin/hdparm. And the assumptions that distro installers make.

Creating yet another set of these tools and standard practices is just not worth it, without bus-agnostic /dev/disk. Sysadmins are going to be annoyed at yet another interface and yet another not-IDE, not-SCSI (and thus second-class) block major.

It's not worth it for me, with working code now, and it's not worth for the next person who wants to add a bus type to Linux.

Unless I am to be creating infrastructure which non-SATA people can use, your suggestion equates to making the SATA driver a second-class citizen, with lots of additional coding for little gain, and with lots of pain on the distro side that must be repeated again and again for each native block driver.

Jeff

You're missing _my_ point.

If it isn't specific to SCSI, then it sure as hell shouldn't BE THERE!

My point is that it's _wrong_ to make non-SCSI drivers use the SCSI layer, because that shows that something is misdesigned.

And I bet there isn't all that much left that really helps.

You adding more "pseudo-SCSI" crap just _makes_things_worse. It does not advance anything, it regresses.

Linus

Sure - there is lots of stuff that ought to be generic error handling/timers/requeue/ioctl stuff that right now happens to be in the scsi layer, and a megaton of user space that only supports it

SATA is SCSI with some legacy crap nailed on the back end, next generation SATA controllers look like scsi, act like scsi, think like scsi. The bang a register count to ten poke a couple of bits and babysit the command world of IDE is dying.

Also with regards to the confusion comment, several vendors now have identical hardware interfaces for their smart SATA and SCSI devices. dpt_i2o has an ATA form, aacraid has a SATA form so the confusion problem about device names also won't be going away in a hurry.

As you see from Alan's message and others, it isn't pseudo-SCSI.

Besides what he mentioned, there is Serial Attached SCSI (SAS), where a host controller can simultaneously support SAS disks and SATA disks. So it's either an IDE driver that does SCSI, or a SCSI driver that does IDE, or a driver that's in both IDE and SCSI subsystems, or... ? Having fun yet? :)

For all these reasons, I continue to maintain that starting out as a SCSI driver, and then evolving, is the best route. The non-SCSI parts leave drivers/scsi, as they should. The SCSI parts stay. The SCSI mid-layer gets smaller. All the while, the driver continues to work. Everybody wins.

Starting out as a native block driver and _then_ adding SCSI support and native queueing and jazz does not sound even remotely like a good path to follow.

Jeff

It _is_ pseudo-scsi.

Or rather, what used to be SCSI is quickly becoming irrelevant. There's almost nothing left, except for the command set. And SCSI is a lot more than the command set, it's the full definition of the signalling from command set to electricals to connectors.

And the other stuff matters. The linux SCSI layer proper is full of the _addressing_ that is part of the SCSI standard proper, and that is pretty much total nonsense outside of that standard (it's starting to be nonsense even inside that standard, since everybody running away fron the old buses and the old addressing).

So we shouldn't call it SCSI, because it clearly IS NOT, whatever you claim. This is a _fact_, I don't see why you argue against it. SCSI has a well-defined definition (or rather, a _set_ of definitions), and SATA ain't there. One is T10, the other is part of T13.

And quite frankly, names matter, and calling it SCSI is clearly wrong. What makes you _think_ it is SCSI is that everybody uses the command set, and all devices are starting to largely just talk MMC-2+.

But calling it MMC-2 is also incorrect, since everybody really talks a superset, and we should just accept that and not try to limit outselves.

Linus

Btw, in case you wonder why I care about names and organization, it's because with the names and organization comes assumptions and expectations.

One prime example of this is cdrecord, and the incredible braindamage that the name "SCSI" foisted upon it. Why? Because everybody (ie schily) _knows_ that SCSI is addressed by bus/id/lun, and thinks that anything else is wrong. So you have total idiocies like the "cdrecord -scanbus" crap for finding your device, and totally useless naming that makes no sense in any sane environment.

Calling something SCSI when it isn't brings on these kinds of bad things:
people make assuptions that aren't sensible or desireable.

Names have power. There's baggage and assumptions in a name. In the case of SCSI, there is a _lot_ of baggage.

Linus

Now that argument I can buy.

There's still helper functions to be created before a native block driver can directly use struct requests for fully native queueing. Brand new device, host registration code. PM, hotplug, yadda yadda. It winds up being a lot of code still, and it not as simple as you and Jens seem to be making the task out to be. That's why I brought up /dev/{disk,floppy,cdrom}...

If all that work is to be done for a brand new, native block driver, we should at least intend on using the code as a bus-agnostic command transport layer, with packages of helpers like my current "libata" doing the command set work (and sometimes, some amount of low-level driver work, where commonality exists).

Jeff

Last I looked, the SCSI interfaces were much nastier than the native queueing, and if there is anything missing I'd rather put it at that layer, instead of making everything use the SCSI layer.

Because when you talk about error handling messes, you're talking SCSI. THAT is messy. At least judging by the fact that a lot of SCSI drivers don't seem to get it right.

In other words: I'd really like to see what you can do with a _native_ request queue driver, and what the probloems are. And maybe port _those_ parts of SCSI to it.

Well, I don't think it claimed to, until today. Still doesn't work?

Linus

The SCSI mid-layer has quite flexible command submission and synchronization. Since each SATA host controller I've seen so far differs in its queueing implementation and limits, this fits perfectly with the existing SCSI set up.

So, short-term, I save a ton of code over a SATA block driver. Long-term, the SCSI mid-layer benefits from the developer attention and becomes more lightweight as we push some generic concepts upwards into the block layer. Just look at how far scsi mid-layer has come in 2.5, versus 2.4! Much more lightweight even now.

So, short-term I disagree. Long-term, I actually agree w/ you, in an indirect sorta way :)

This isn't an issue for me. I have to do my own error handling, in fact. I just define ->eh_strategy_handler, and do my own thing. SCSI mid-layer nicely provides a kernel thread and command synchronization before and after it calls ->eh_strategy_handler.

I considered a native block driver, or perhaps a native block driver for SATA and SCSI pass-thru for SATAPI.

Actually getting down to coding, I see it as a huge amount of work for little gain. You have to consider all the userspace interfaces, sysfs and device model support that wants coding, -after- you're done with the basic SATA block driver. Userland proggies already exist for scsi.

(more on this in next reply)

Nope. Not before or after. (even without the patch, it should have worked in some amount of compat mode)

Jeff

Tangenting a bit:

What does the block layer need, that it doesn't have now?

Each major subsystem right now is re-creating driver classes (floppy, tape, disk, ...) and that should be moved up and made more general. People should use /dev/diskX, /dev/floppyX, /dev/cdromX etc. without having to worry about IDE or SCSI or Jeff's SATA or whatever. Registration of majors/minors/CIDR/etc. sysfs. host controller-specific struct request_queue settings. All these have to be recreated each time a new native block driver is created. If you peer closely at some scsi drivers already merged, you see that too chose to translate SCSI rather than re-create all the junk necessary for a native block driver. I'm definitely not the first to do what I did. :)

When such code moves up into the block layer, then we can have a unified userland for doing class-specific activities, and then have a few bus-specific tools for the ATA- or SCSI-specific needs not met by class-general code.

As it stands now, I think a new native block driver creates more user confusion and pain than it solves, in addition to saving developer pain, if you consider all the device classes and userland tools and such that need writing.

Jeff

Not at all. This is the thrust of _my_ worries.

Exactly. I'd _love_ for people to really think about this.

Linus

In discussion with Jeff, it seems most of what he wants is already there. He just doesn't know it yet :-)

Maybe that's my problem as well, maybe the code / comments / doc / whatever is not clear enough.

Jens Axboe

hehe. Here's a salient point:

native block drivers are typically used in one of two ways: creating a whole subsystem (ide, scsi), or servicing a single host (dac960).

I am doing the first: creating a whole subsystem. The infrastructure involved in that, over and above what block already provides, is that part I dread coding.

If I am to code that, I want to do so ONCE. And that means a bus-agnostic /dev/{disk,cdrom,tape}. Not /dev/{ad,acd,at,ag}.

Jeff

Another important point is time.

I continue to agree that a native block driver is the best direction.

But with 2.6.0 looming, I think it's best to evolve my ATA driver to be a native block driver from a scsi one. Not start out as a native driver. That's significant pre-2.6 churn.

Or, it lives out-of-tree until 2.7 and people with SATA hardware have to go out-of-tree for their driver for months and months, until the working driver is deemed sufficiently native :) In the meantime, distros wanting working SATA will just ship the SCSI driver as-is. :(

Jeff

I don't think that makes any sense. If you really do find missing functionality that are candidates to be generic block property, we can add them.

I don't know why you are even worrying about this yet, time will decide what happens. As it stands right now, I still consider your driver to be something to play with, not something that should go into the kernel anytime soon.

Maybe in 6 months time it has evolved to be something really great, we add it then. Right now you are still in the design stages in some areas.

Jens Axboe

Even if it did it would at best be a toy. The core IDE layer doesn't handle SCSI errors properly (needed for ATAPI) except using ide-scsi. It doesn't handle hot plugging of devices, it doesn't handle tagged queueing very well, it hasn't the slightest idea about multipath (SATA2 can do), it doesn't know a lot of other things either.

SATA and especially SATA2 is basically SCSI with some slightly odd ways of issuing READ10/WRITE10 to disk devices. A "native" driver would basically be a copy of most of drivers/scsi.

I actually think thats a positive thing. It means 2.5 drivers/scsi is now very close to being the "native queueing driver" with some additional default plugins for doing scsi scanning, scsi error recovery and a few other scsi bits.

Hey, that may well be the way to go, in which case the core stuff should be renamed and moved off somewhere else. Leaving drivers/scsi with just the actual low-level SCSI drivers.

Linus

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.

Its getting close.

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.

No big deal here, ATA will get it too.

CPU polling is faster than IRQs?

So fix it ;-).

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

Regards,
--
Bartlomiej

social engineering removed

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.

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

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

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.

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 :)

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.

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 :)

Jeff

Its not that hard, but nevermind.

Okay, I misunderstood.
This is cool, but you are using ie. outb not only in taskfiles.

Good.

Silly excuse ;-).

Thanks,
--
Bartlomiej

Btw, Jeff, while I agree about not boring about old PATA hardware, I'd still like to see support for MDMA modes in there. For once, there is no real difference in supporting both UDMA and MDMA, it's really just a matter of extending the range of the "mode" parameter, and I'd like to be able to use the driver on configs like pmacs which typically have a U/DMA capable channel for the internal HD and one MDMA only channel (ATAPI CD/DVD, ZIP) without having to play bad tricks to get both drivers up.

Ben.

We'll see... I would really like to ignore MDMA. For the reasons just outlined in replies to Linus, PATA support is quite useful in limited situations, but is not at all the focus of the driver. When situations arise where special support for some PATA situation is needed, I will most likely just say "use drivers/ide"...

Jeff

JG,

This is the right move after months of debating ideas. Migrating the contents of ./drivers/ide/pci to scsi is reasonable too. This will allow the legacy drivers to die.

Taskfile came to late to be really useful, it is now best used as a model to tackle FIS/FPDMA mapping for SATA II.

Linus, my professional opinion is to follow Jeff's direction for 2.5/2.6. This will allow Linux to push open source to the hardware vendors. There are several bastardized scsi-ide drivers in ./scsi.

pci2000.c,h :: pci2220i.c,h :: psi240i.c,h + psi_*.h :: eata*

ATAPI is nothing more than Bastardized SCSI beaten with an ugly stick.

Packet-Taskfile is more than painful, and I am not in the fighting mood.

Cheers,

Andre

Andre Hedrick
LAD Storage Consulting Group

megaraid, i2o, 3ware, aacraid all also drive IDE devices too now Promise new driver is using the scsi layer as well (because they do command queuing as well as drive tagged queue stuff). I've been hacking on the SI stuff a bit and its also apparent our IDE PATA layer won't support that well in a hurry either since it also has command buffering.