linux-kernel - Re: [PATCH] libsas: support NCQ for SATA disks

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20061017224221.89332.qmail@web31804.mail.mud.yahoo.com>
Date:	Tue, 17 Oct 2006 15:42:21 -0700 (PDT)
From:	Luben Tuikov <ltuikov@...oo.com>
To:	James Bottomley <James.Bottomley@...elEye.com>,
	Jeff Garzik <jeff@...zik.org>
Cc:	brking@...ibm.com, "Darrick J. Wong" <djwong@...ibm.com>,
	linux-scsi <linux-scsi@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Alexis Bruemmer <alexisb@...ibm.com>,
	Mike Anderson <andmike@...ibm.com>
Subject: Re: [PATCH] libsas: support NCQ for SATA disks

--- James Bottomley <James.Bottomley@...elEye.com> wrote:
> On Tue, 2006-10-17 at 07:15 -0400, Jeff Garzik wrote:
> > Brian King wrote:
> > > This doesn't look like the right fix for the oops you were seeing. The
> > > SAS usage of libata has ap->scsi_host as NULL, which indicates that
> > > libata does not own the associated scsi_host. I'm concerned you may
> > > have broken some other code path by making this change. I think the correct
> > > fix may require removing the dependence of ap->scsi_host from
> > > ata_dev_config_ncq. 
> > 
> > Yep.  I had already mentioned this on IRC.
> 
> I understand, but right at the moment, my priority is sorting out the
> aic94xx driver so that it works with SATA devices.  It has become
> apparent that there's some need for a bit of code sorting out in libata
> to drive intelligent sas controllers, so we can take a look at bugs in
> ata_dev_config_ncq() when someone's time frees up to look into the
> libata issues.

Just to give people some freedom of choice:

I feel the need to mention that my code as I support it, the
SAS Stack, does include fully T10-complient SATL, which does SAT on
per device basis, leaving the transport be whatever it need be.
I.e. no messing around with "ata ports" or "hosts" or what not.

A provider (SAS Stack, software ATA emulation, whatever) simply
_registers_ with SATL, declaring in a structure of method stubs
what it can do, and then SATL drives the device.  This is similar to
how my SAS Stack works with SAS LLDD (the bottomleyised version of my
code uses a libsas "on the side" instead of being a fully fledged
layer as intended and originally written).

The SATL also does SATA feature configuration as per the declared
capabilities of the LLDD (aic94xx, or whatever) _and_ as per the
device declared capabilities.  I.e. if one or the other doesn't
support it, then it is turned off, if both support it it is on.

The SATL also supports NCQ, S-ATAPI, full error recovery (NCQ, etc).

It also supports MODE SENSE, MODE SELECT, ATA Pass-through (all protocols),
S-ATAPI, etc, etc, as per SAT.*

Bottomley has simply made a decision for you, what kind of code
you should be using, what it supports and how it supports it.

Good luck everyone!
     Luben

* For example, I exclusively cut CDs/DVDs using a S-ATAPI DVD-RW device
attached to an expander using the SAS Stack and SATL.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/