lkml.org 
[lkml]   [2005]   [Sep]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: I request inclusion of SAS Transport Layer and AIC-94xx into the kernel
    On 09/28/05 18:43, Andre Hedrick wrote:
    > I have a vested interest in the improvement of the Linux SCSI Core and
    > wider adoption and support for SATA II and SAS controllers with their
    > associated domains and transport.

    Us and other companies too.

    > Proving a better design with a migration path for integration is the key
    > for success; however, I am not the person to be the political voice in the

    Yes, _it is_ the key to success.

    > James is king of the hill, and is reasonable to a point. James also

    Which "hill" is the question. If he were reasonable, he'd
    understand that the two technologies _are_ completely different and
    distinct and he'd not try to shove HIS solution down my throat.
    Just as I do not shove my solution in his throat.

    The whole point is that MPT-based (IOP on package) solutions
    _do not_ need a Transport Layer, since that Transport Layer
    _is_ already present: in the firmware _and_ access to it
    is _firmware_ dependent.

    All the while open transport solutions (ours and apparently
    Broadcoms') _expose_ the whole infrastructure and _give_ you
    the chip as an interface to the interconnect. So you actually
    _need_ a transport management layer. Now that transport
    management layer sits _below_ SCSI Core and SCSI Core is
    _unaware_ of the transport.

    > follows a model of generalization v/s specific design. Argh, this is not
    > going to be an easy one to explain or back away from now. Erm, inclusive
    > API design is where I am wanting to go with this thought.

    You can have inclusive API design for chips like AIC-94xx and BCM8603,
    because they <see paragraph above>.

    MPT-based ones <see paragraph above> would also use inclusive
    design _for MPT-based chips_.

    > Have you and company considered the approach of mapping to a library of
    > sorts?

    Hmm, it is not a library.

    It is a layer, again, because of what the chip actually is, and because
    of what it implements.

    Take a look at the announcement text, I do give some description there
    and in the code the drivers/scsi/sas-class/README file describes
    the event/managment infrastructure. Also you can take a look at the code.
    http://linux.adaptec.com/sas/

    What you'll see in the code is:

    hardware implementation (interconnect, SAM 4.15, 1.3)
    firmware implementation (interconnect, SDS, SAM 4.6, 1.3)
    LLDD (SAM, section 5, 6, 7)
    Transport Layer (SAM 4.15, SAS)
    SCSI Core (SAM section 4,5,8)
    Commmand Sets (SAM section 1)

    A very nice explanation in latest SAM4r03,
    section 4.15 The SCSI model for distributed communications.

    Now for MPT based solutions you have:

    LLDD (SAM, section 5, 6, 7)
    SCSI Core (SAM section 4,5,8)
    Commmand Sets (SAM section 1)

    You see? No Transport Layer between LLDD and SCSI Core!
    Why? Because all this work is done in FIRMWARE!

    That is, the LLDD exports the LUs right into SCSI Core,
    So in effect there is _no_ need for a software Transport
    Layer.

    Can we have a video/tele conference on this?

    Luben

    -
    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/

    \
     
     \ /
      Last update: 2005-09-29 17:07    [W:3.484 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site