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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
