[lkml]   [2005]   [Sep]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: I request inclusion of SAS Transport Layer and AIC-94xx into the kernel
    Luben Tuikov wrote:
    > On 09/27/05 17:55, Jeff Garzik wrote:
    >>* Avoids existing SAS code, rather than working with it.

    > No, it's the _other_ way around. There is NO existing
    > SAS code.

    Incorrect, just look in the latest upstream kernel.

    >>* Avoids existing SATA code, rather than working with it.
    > FUD! Why? It does _not_ use SATA code at all.

    That's the problem.

    > Why? SATA devices are discovered on the domain, but
    > there is _no_ SATL in the kernel to represent them.
    > And libata is _not_ SATL. The reasons are that

    libata-scsi.c is the SAT translation layer.

    >>* Avoids (rather than fix) several SCSI core false dependencies on HCIL.
    >> Results in code duplication and/or avoidance of needed code.
    > No, not true. It _integrates_ with SCSI Core. The sad truth
    > is that SCSI Core knows only HCIL.

    That's something that needs fixing, for SAS.

    > I repeat again that I had this code _long_ before Christoph
    > ever dreamt up SAS. And he got my code via James B sometime
    > before OLS this year. I think he got it July 12, 2005.
    > The question is: why didn't _he_ use the solution already
    > available?

    Because it has the problems listed time and again.

    > You have to understand the differences between MPT and open
    > transport architecture.
    > At some point I thought Christoph seemed to have understood it.
    > Now I'm not sure any more.
    > Now since the open transport solution completely encompasses
    > and _absolves_ MPT, it is not hard for an MPT driver to
    > generate a bunch of events and use that infrastructure.

    The SAS transport class is designed to support both firmware-based
    devices like MPT, and non-firmware devices such as Adaptec.

    Sure it might need patches -- send patches, work with people, rather
    than ignoring existing work.

    >>* Maintainer reminds me of my ATA mentor, Andre Hedrick: knows his
    >>shit, but has difficulties working with the community. May need a
    >>filter if we want long term maintenance to continue.
    > I take offence in your liking me to Andre -- I don't know
    > Andre personally, but is seems that you're expressing personal
    > opinion against him, against me and labeling me in some way.
    > I take offence in that, Jeff.
    > Why are you making this a _political_ and personal game?
    > All you're doing is trying to aliken me to someone and
    > brandish me as someone I'm not.
    > This is rude, offensive and done in desperation.
    > Shall we concentrate on the _technical_ part of
    > the argument?
    > I repeat again: _technical_ part of the argument.

    We've been over the technical stuff time and again. That's the
    maintainer problem. We need someone who will listen to the community.

    >>Easy path: make Adaptec's solution a block driver, which allows it to
    >>sidestep all the "doesn't play well with others" issues. Still an
    > What _exactly_ does it mean "don't play well with others"?

    It means not taking feedback, and working around rather than with the
    SCSI core.

    >>Adaptec-only solution, but at least its in a separate playpen.
    > I'm sure James Bottomley will move from SCSI Core to the block
    > layer as he did for IDR. hehehe :-)
    > And no, it is not Adaptec's only solution. Your BCM8603 SAS
    > LLDD when you write it could use it without any problems.
    >>Hard path: Update the SCSI core and libata to work with SATA+SAS
    >>hardware such as Adaptec's.
    > Cannot do for libata -- ever. Why? You know best: because
    > libata uses direct access to the hardware! There is no
    > layered architecture.

    Then you don't understand the ->qc_{prep,issue} hooks. That should get
    you 90% of the way there, if not 99%.

    > What you need to do is to write a SATL layer, just as you can
    > see in SAT-r6, page 2, Figure 3. I'm on top of this already.

    Re-read libata-scsi.c, and submit any patches you feel are needed.

    > The code doesn't alter Linux SCSI or anyone else's behaviour.
    > It only _provides_ SAS support to the kernel.

    That's one of the problems: It should update the SCSI core.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-09-28 04:04    [W:0.030 / U:11.180 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site