On 09/27/05 22:02, Jeff Garzik wrote:
> 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.
Yes, because it was Christoph's code submitted right after
I submitted and JB took his code right in.
Again, I had the infrastructure ready _before_ OLS.
> libata-scsi.c is the SAT translation layer.
Not quite.
It has potential to become SATL but at its current
form it cannot be:
int ata_scsi_queuecmd(struct scsi_cmnd *cmd, void (*done)(struct scsi_cmnd *))
{
struct ata_port *ap;
struct ata_device *dev;
struct scsi_device *scsidev = cmd->device;
ap = (struct ata_port *) &scsidev->host->hostdata[0];
If I want to use that I have to _simulate_ ata_port.
Furthermore, scsidev->host->hostdata may not point
to ata_port for SATA devices over a different transport.
Ideally SATL is just a _data transformation function_ and
getting to the ATA device is transport dependent.
Jeff, would you be accepting patches?
>>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.
Would you be accepting patches for the creation,
and use of "struct scsi_domain_device { ... }"?
This would be a "SCSI Device with a Z Port".
Z could be target or initiator (most likely just T).
Then for each scsi_domain_device, SCSI Core does
REPORT LUNS and then INQUIRY for each LU it found.
The old (current) code would still say as is, unchanged,
since it supports older, broken hardware.
Would you be accepting patches for this?
>>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.
What problems when there was no other code around.
Look at it this way: _their_ code doesn't integrate
with ours. See?
I simply cannot take an argument like this:
"Because it has the problems listed time and again."
You have to be specific.
> The SAS transport class is designed to support both firmware-based
> devices like MPT, and non-firmware devices such as Adaptec.
No, it never has been. It is an _attribute_ exporting framework
only.
If you understood how different those architectures are,
you'd understand what I mean.
> Sure it might need patches -- send patches, work with people, rather
> than ignoring existing work.
I do not _know_ how to consolidate the completely broken
"design" set forth by JB and company.
It is _completely_ not to SAM spec.
Exporting attributes from MPT-based drivers is not the same
as managing a transport.
I repeat again:
* MPT _hides_ the transport and the managment
of the transport from you -- so in effect there is
nothing to manage.
* MPT gives you Logical Units to work with, NOT ever domain
devices or anyhing domain like.
* MPT gives you a SAM/SPC hook to hook _right_ into SCSI Core.
_This_ is why their LLDD _can_ use the host template.
But an AIC-94xx and BCM8603 _is_ NOT a scsi_host material. It is just
an interface to the interconnect.
To convince yourself of this: take a look at the _members_ of
the scsi host/scsi host template: nothing in that structure is
presented in the chip -- UNLIKE old Parallel SCSI device drivers.
The scsi host template was written to cater to _old_ (then new)
Parallel SCSI drivers! Times have changed! Time to evolve.
> We've been over the technical stuff time and again. That's the
> maintainer problem.
No we haven't been over the technical stuff time and again.
> We need someone who will listen to the community.
I bet you're melting people's hearts when they read this.
So to summarize for corporate management what you're saying
here is:
- you're saying that I do not listen to "the community",
- you're saying that I'm an _outsider_ to "the community",
- you're saying that I'm no good to work with you, since
you are part of that community but not me.
That is you cannot take it that someone will tell
"the community" anything. "The community" knows all and it
knows best.
So in effect there are no good and knowlegable engineers
anywhere but in the "Linux community".
That is there is no people with new ideas, better ideas,
innovative ideas, more knowlege about certain subject matter,
_anywhere_ but in the "Linux community".
So in effect, there will never be an "outsider" who will
come in to the "linux community" and change things around,
no fresh ideas, no better (right?) way to do things.
"The community" is not going to listen to anyone but only to
already politically established members on _any_ subject
matter, even technical, even from "outsiders" who work with
the technology every day.
>>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.
So does this mean, that if I submit patches "fixing" (oops,
not meant to hurt anyone's bal^w^w^wpride) SCSI Core, they
will be accepted.
Or do you want me to do "your way of SAS"?
Maybe JB et al, should write the "Linux SAS spec" and
then we can recommend this to T10.org, so they can scrap
their version and use "the community's"?
I hear there was such a suggestion on the mailing lists
for ATA and T13.org, but I'm sure I'm misunderstanding
something here as usual.
> Then you don't understand the ->qc_{prep,issue} hooks. That should get
> you 90% of the way there, if not 99%.
But I have to simulate struct ata_port, Jeff.
Which isn't so bad, but speaks about the design.
>>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.
Will do.
>>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.
Thank you for admitting this -- you're the first and only
member of "the community" (since I'm not a member apparently)
to admit this.
Luben
-
: 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
