Luben Tuikov wrote:
On 10/18/05 12:44, Jeff Garzik wrote:
Wrong. DMA boundary is a trivial counterexample.
I've addressed DMA boundary in another email which I posted 2 hours ago
to this list.
Our controller has no limitation as to DMA boundaries. All 64 bit space
is fair game. There is also no sg list size limitation.
These are an Adaptec-only assumptions, at the present time.
The DMA boundary, s/g stuff etc. are there for the LLDD to communicate
that to the SCSI and block layers that need that info.
Once you encounter non-Adaptec hardware with limitations on these
details, you'll either be forced to reinvent the wheel, duplicating this
stuff, or backtrack and use the scsi-host-template as it was intended to
be used.
For this reason I did not overengineer the code.
Adding HW specific stuff is trivial. In fact I'll add it to my code
today and update the code.
The aic94xx code does include it: struct hw_profile { ... }; embedded in
struct asd_ha_struct { ... }; See drivers/scsi/aic94xx/aic94xx_hwi.h.
Exactly the same concept applies to struct sas_ha_struct { ... };.
I'll embed struct hw_profile { ... }; into it later today. sg lists
max lengths, DMA maps, would be there (all ~0).
No. This would simply be duplicating more of the SCSI core, because you
don't like scsi-host-template.
What it actually means, as the name _also_ suggest is a device on
the domain, which is transport addressible. See SAM chapter 4 and 5.
I'm discussing the topic at hand at a higher level than SAM.
Can you give us a reference to this "higher level than SAM"?
I'd like to read about it.
<shrug> Any literature on messaging, networks, and RPC.
Block layer, and Dragonfly BSD concepts are along these lines.
You cannot care about "remote" ports -- some types of device have _no_
port layer, as well you only care about the port "half" on your end.
SAS is quite clear on that.
Remote ports deals with the other half of the connection. You gotta
deal with it somewhere.
I do deal with it. Just look at the code and how it shows you the
ports that have been formed (from Announcement 1 at
http://marc.theaimsgroup.com/?l=linux-scsi&m=112629509826900&w=2)
The quoted part you deleted was referring to the existing SAS transport
class, unless I'm completely lost in this thread.
* very poor SATA interface
Hmm, no sorry, I'm not going to accept the BS FUD, generalized
comment.
If it doesn't interface with libata, the current SATA interface, then
the code needs improvement. Its a statement of fact.
Aaah, _that's_ what you meant. "If it doesn't use my code, it bad code."
If it duplicates SCSI<->ATA translation, and ignores existing kernel
facilities...
Look, I've even included comments on how to integrate the code with
a SATL (which libata is _not_, but it does implement some SATL tasks).
I know that you're pushing for libata-scsi to become SATL, but this
is hard when your devices belong to a port in an _array_.
I've simply stated that there will not be more than one SCSI<->ATA
simulator in the kernel.
All implementation decisions trickle down from that overall path.
And you're forcing libata-scsi to be SATL which it is currently not.
I'm describing the path that needs to be taken, moving forward.
SAM is ultimately message passing RPC over a network.
While I understand what you mean, according to the Abstract it is:
"This standard specifies the SCSI Architecture Model.
The purpose of the architecture is to provide a common
basis for the coordination of SCSI standards and to specify
those aspects of SCSI I/O system behavior that are independent
of a particular technology and common to all implementations."
Not all transports would be a "network". Anyway this isn't important
to the tasks at hand.
It's quite important.
SAS is networking -- we have packets, we have routing.
* Using scsi_scan_target() would allow us to use the normal LUN scan
Again not my code. Normal LUN "scan" is done through REPORT LUNS
as shown in sas_discover.c as I posted both functions to this list
in a recent email.
SCSI core does REPORT LUNS, so we should use that.
HCIL.
That's a reason to work with the SCSI layer to update it, not work
around it.
* Avoid writing a separate SMP driver for now, and see how things
shake out with future SAS+SATA hardware.
No such intentions. SMP should not be in a separate driver.
For SMP you need _addressing_ and the solution to this problem
has been showin in driver/scsi/sas/README and in the announcement
emails to linux-kernel and linux-scsi here:
http://linux.adaptec.com/sas/
As I said above, this entire thread is talking about your code, and how
it will integrate into the upstream kernel. There is little value in
repeatedly posting a URL to code we're already discussing.
Well, in all honesty and actuallity the code has already been integrated
and it works. The link is here:
http://linux.adaptec.com/sas/
How many times are you going to post this link in each message?
libata is two layers: SATL and HW interface -- given ata_port and how
Obviously. ls(1) would have told you that:
[jgarzik@pretzel sas-2.6]$ ls drivers/scsi/libata*.c
drivers/scsi/libata-core.c drivers/scsi/libata-scsi.c
The hardware interface is separate from the SCSI simulator.
The exported to the kernel ata_scsi_queuecommand() defined in
libata-scsi.c dereferences struct ata_port.
That is, if, say SAS Transport Layer wanted translation for
a SATA device it would have to conjure up ata_port, which
would need to be made up.
Again, I'm stating the path to move forward. Obviously, code changes
are needed. Rather than continually pointing to a URL, I'm trying to
point out where those code changes should occur.
Jeff
-
: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
