Messages in this thread | | | Date | Mon, 17 Oct 2005 13:38:44 -0400 | From | Jeff Garzik <> | Subject | Re: [PATCH] libata: fix broken Kconfig setup |
| |
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 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/
| |