Re: [PATCH] libata: fix broken Kconfig setup

[Jeff Garzik <jgarzik@pobox.com>]

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