On 09/30/05 20:33, Jeff Garzik wrote: > Luben Tuikov wrote: > >>But none of the ideas: 64 bit LUN, HCIL removal, etc., >>were accepted with "submit a patch". > > > I concede this may have been the response in the past. Its not, now. > > > > >>>So you're saying fixing the current SCSI subsystem once *now* costs >>>more than applying all *future* SCSI fixes to _two_ SCSI subsystems, >>>handling bug reports for _two_ SCSI subsystems, etc. >> >> >>I'm saying that the current "old" one is already obsolete, >>when all you have is a SAS chip on your mainboard. >> >>All you need is a small, tiny, fast, slim SCSI Core. > > > Then don't use it at all. Write a block driver, if you really feel we > need two SCSI cores. > > > >>Politics: "Nah, whatever you say, specs are *crap* and we'll >>do it our way. We are not interested in your way, even if it >>were better. Oh, and BTW, REQUEST SENSE clears ACA and LUN >>is a u64." > > > This is a misrepresentation. -We- understand the stuff you have posted. > > But you continue to demonstrate that you simply do not understand the > existing SCSI core code. > > The SAS transport class supports commonality across all SAS > implementations. This includes both MPT and Adaptec 94xx. > > SAS transport class + libsas supports software implementations of SAS, > including transport layer management. This includes Adaptec 94xx but > NOT MPT. You almost get it right, other than the layering infrastructure. The SAS Transport Layer is a layer in its own right. It is not a "libsas". MPT and open transport a very different, one hides the transport, i.e. the transport layer is in firmware; the other exposes it and needs a transport layer. See the pictures here: http://marc.theaimsgroup.com/?l=linux-kernel&m=112810649712793&w=2 Luben - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
