From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Fri, 2 Oct 2009 01:15:20 -0400 To: 9fans@9fans.net Message-ID: In-Reply-To: <<18364.1254459813@lunacy.ugrad.cs.cmu.edu>> References: <<18364.1254459813@lunacy.ugrad.cs.cmu.edu>> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] plan9 on vmware esx Topicbox-Message-UUID: 7bafad3a-ead5-11e9-9d60-3106f5b1d025 > Run in fear. > > Despite having a number which is just a wee bit higher than the > things supported by the existing Plan 9 NCR/LSI SCSI driver, > this is an utterly different beast, based on LSI's "Fusion" > architecture, which in theory simplifies things vastly for the > host over the old sequencer/script architecture, but all of the > simplification is balanced out by vast complexity additions in > other areas (addressing devices in terms of target and LUN is > obsolete, so there are two or three other ways that devices can > identify themselves, and a host is supposed to set up a mapping > from long identifiers to short ones for, and for some reason I > didn't get on first reading the host is supposed to use the same > mapping across reboots). regardless of what one things of the fusion architecture, most of these complications are direct results about how modern scsi works; any modern scsi driver will have the same issues. the address of a scsi device will have depends on the protocol used for disk access. sas for example uses "sas addresses" aka a wwn. if you avoid dealing with expanders, sas simplifies quite a bit. sdorion (contrib quanstro/sd) is a "combined mode" driver. combined mode means that it is able to talk to either sata or sas hardware. - erik