Messages in this thread | | | Date | Tue, 27 May 2003 02:07:36 -0400 | From | Jeff Garzik <> | Subject | Re: [BK PATCHES] add ata scsi driver |
| |
Linus Torvalds wrote: > On Mon, 26 May 2003, Jeff Garzik wrote: > >>Correct, but precisely by saying that, you're missing something. > > > You're missing _my_ point. > > >>The SCSI midlayer provides infrastructure I need -- which is not >>specific to SCSI at all. > > > 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.
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? :)
> On 27 May 2003, Alan Cox wrote: >>> 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.
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
- 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/
| |