On Wednesday, September 28, 2005 5:42 AM, Luben Tuikov wrote:
> > Hi Luben,
> >
> > OK, Man are you alright?
> >
> > I've heard of other vendors planning to
> > provide solutions where sas is implemented
> > in firmware, similar to MPT. Christophs
> > sas layer is going to work with other
> > solutions, don't think of it being
> > MPT centric.
>
> Where in what I said above do I say that it will _not_
> work with _other_ MPT based drivers? Nowhere!
>
> Yes it _will_ work with other MPT-like drivers but
> to cut and paste again from above:
> * MPT based only,
> * doesn't follow a spec to save its life,
> * far inferior in SAS capabilities and SAS representation
> again, due to the fact that it is MPT based.
>
> When I say MPT, I do not mean MPT(R), I mean MPT as
> in technology, not as in trademark.
>
> Luben
>
Luben: I guess you didn't get what I meant.
I was referring that there are other
*vendors* (not LSI, e.g MegaRAID) that are
working on sas solutions with sas firmware
implementation. One that comes to mind is
Intel SunRise Lake, which is non a MPT based
solution, that would work with Christophs
Sas Layer. There maybe others, such as emulex.
Perhaps James S. could comment on that.
Eric
On 09/28/05 11:15, Moore, Eric Dean wrote:
> Luben: I guess you didn't get what I meant.
>
> I was referring that there are other
> *vendors* (not LSI, e.g MegaRAID) that are
> working on sas solutions with sas firmware
> implementation. One that comes to mind is
> Intel SunRise Lake, which is non a MPT based
> solution, that would work with Christophs
> Sas Layer. There maybe others, such as emulex.
> Perhaps James S. could comment on that.
This means that they have an IOP on the same
silicone or on the same packaging.
This means, again that they'd done all transport
specific tasks in the FW (by the IOP).
Again, such solutions do _not_ need the
SAS Transport Layer.
They don't even need the attributes, but
as a "nice to have" feature, you can use
transport attributes.
You, as technical person, should recognize
the different needs and thus the different
solutions between LSI's implementation and
Adaptec's.
I'm surprised you never chimed in in defense
of the _different_ technology.
See, I've mentioned many times that the two
radically different technologies can coexist.
But I've not heard any technical word
from the other guys: you.
Luben