Re: [PATCH] libata: fix broken Kconfig setup

Jeff Garzik
2005-10-17T17:38:49Z

Linus Torvalds wrote:
> The _best_ choice as far as I can tell, is to just dis-associate SATA from
> SCSI entirely. Even if it's an implementation choice, we could make it a
> "select SCSI" instead of "depends on SCSI", so that from a _logical_
> standpoint the user could just select SATA support without even knowing
> that the kernel happens to need the SCSI layer for it.

Yep. That would happen as a side effect of moving the code to
drivers/ata, even.

> Of course, eventually I still hope that SATA could be done on the block
> layer instead of even depending on SCSI at all, but hey, that's a totally
> different issue.

If you look at libata-scsi, the code is simply a SCSI simulator that
calls a _clean_ and _separate_ libATA API.

Other code -- such as a block-layer driver -- could use this same API.
I think Bart has mentioned he has early code to do this, or at least
ideas on how to do it.

I made a promise to you, to do it at the block layer, and I intend to
keep my promise. :) It just takes years to get there. The two main
reasons for using SCSI were/are:

* provides a bunch of useful _generic_ infrastructure

* has a very high Just Works(tm) value for distro installers and users,
where code already exists for /dev/sdX. I learned the hard way with
drivers/block/sx8.c that adding a new block device involves coordination
with multiple distros :(

I dream of a /dev/disk, perhaps reusing and expanding /dev/sdX's block
majors, but that may be unrealistic.

Jeff