On 09/27/05 11:53, James Bottomley wrote:
>>Christoph, why diseminate FUD, when we can concentrate on the
>>_technical_ merits of SCSI and SAS instead?
>
>
> That's what *we* are concentrating on. Technically, I have no problem
Nah. You're concentrating on blocking new drivers and _innovation_
from getting into SCSI Core.
Just look, for all these years you've been "maintaining" SCSI Core
it still uses HCIL, LUNS are u32, and you think that REQUEST SENSE
clears ACA, and scsi core has no representation of targets to save
its life.
It just hurts us all.
> with the aic94xx driver being based on a domain device. However, you
> cannot have two separate transport classes for SAS. So these two need
> to be unified before this driver becomes includable.
Apparently you do _not_ understand what the SCSI architecture
model is, again I refer you to the _picture_ here:
http://www.t10.org/scsi-3.gif
Now,
1) MPT _gives_ you LUs -- all transport _and_ SCSI specific work
has already been done for you.
2) With MPT you export attributes by poking, in a firmware
_dependent_ way, into the firmware of the controller.
That is, _all_ the "stuff" below SAM, as you can see in the picture
link, happens in the firmware! What the firmware _gives_ you in a
_uniform_ way is SAM/SPC objects only (via the LLDD) so you can
register the LUs with SCSI Core, etc.
None of this is true for the SAS Transport Layer and
the AIC-94xx driver and BCM8603. That is, for those solutions
the transport (SAS) architecture is exposed right down to
the phy/link layer.
So you _need_ transport management. And since SAS sticks
to SAM so nicely and is so very well layered, it implements right
into what you have in the SAS Transport Layer.
> It looks to me to be a fairly simple exercise to unify these two classes
> giving LSI a functional interface and you a domain device based one and
> removing all the duplication of mid-layer functionality as part of doing
> this.
Ok, I'm aware that you're well aware that very few people actually
understand indepth MPT and other architectures.
You're posting FUD here, and hope that, since no one understands things
indepth, you can post anything you want, and sound credible.
I repeat again:
Those are two *radically* _different_ and _distinct_ technologies.
What MPT does is _everything_ *below* SCSI Core in terms of
SAS Transport Layer and AIC-94xx LLDD.
That is all the work you see done in the SAS Transport Layer
and in AIC-94xx IS DONE ALREADY IN THE FIRMWARE!
What our solution and apparently BCM9603 does is expose _all_
that.
What you need to do is:
- Let the code in _now_, as is.
- Let _people play_ with it as hardware comes more available.
I said "people" not necessarily you and/or Christoph.
- Let it evolve in the hands of the people.
- Hear feedback from the people.
- Accept patches.
- Let it evolve.
IOW, do not bastardise it now when you have _no_ SAS or SCSI
expertise, or hardware (well, maybe you have some on the way
from your friends at XYZ).
>>The SAS Transport Class (your an JB's incarnation) is _not_
>>a management infrastructure, it was _never_ _intended_ to be.
>
>
JB's statement A:
> Actually, it was intended to be such. The sysfs components of the
> transport class are the unified management interface to the transport.
If it was _ever_ intended to be such, then it would sit
_below_ SCSI Core _and_ SCSI Core would NEVER be aware of it.
(just as it is on the picture, see?)
Even the _name_ suggests it: SCSI transport _attributes_,
and it is a template to export _attributes_.
You *CANNOT* write a template for _all_ transports, since this
is what SCSI Core is supposed to be! This is what
SAM/SPC _is_! This is what SCSI Core should be striving to.
The transport management layer sits _BELOW_ SCSI Core,
and _manages_ the particular transport, just like the SAS Transport
Layer. SCSI Core does only SAM/SPC tasks, and is _unaware_ of
the transport. (How hard is this to understand?)
See the _pictures_ on t10.org and the "techno-gibberish" posted
there?
JB's statment B:
> No, the point of a transport class is to export the underlying
> attributes of the actual devices that are present. This is supposed to
Exactly! And this statement B here, contradicts your statement A) above.
Note: it is a transport _class_, _not_ a management _layer_, which is
what you have with the SAS Transport Layer.
> be independent of the driver used to connect to them (and that's what
> your sas class breaks).
Mine is _not_ a class. It is a transport layer to _manage_ and drive
SAS LLDDs.
LSI's driver is NOT, to repeat it is NOT a SAS LLDD! It is an *MPT* LLDD.
Your "transport attribute class" provides hooks for exporting
_attributes_ from MPT-based LLDDs.
It does _NOT_ provide for a management infrastructure:
1) because there is none needed -- the LLDD is MPT and you're providing
attribute exporting only,
2) All this is _firmware_ implemented.
I repeat again: you cannot have a single _template_ for all-protocol
_management_ as you're implying.
For the record: I think MPT is a wonderful technology in its right
and the SAS LSI's solution should've been accepted right when it
was posted, since it didn't have any SAS in it. The only thing
it had was a few different PCI IDs, AFAIR looking at the patch.
> I've told you before, if you find something that's broken send a patch
> in to fix it. I've already told you why the code in sas_discover can't
> work for other drivers (although I still don't have an explanation from
Nah, lets not go with this BS: "I've already told you...", it just
doesn't work. Be specific. See above how much effort I put in
repeating myself over and over and over again. And I put
the effort to actually type everything out.
> you of why scsi_scan_target can't work for sas_discover).
Why? Because it uses HCIL? Because LUN are represented as u32?
Because you think that a LUN is a "u64". Because you think that
REQUEST SENSE clears ACA?
>>What needs fixing is, SCSI Core to
>> - not use HCIL,
>> - use 64 bit LUNs,
>> - know about SCSI devices with Target ports,
>> - proper representation of SCSI Domains
>> (FC, USB, IEEE 1394, Infiniband, SAS, iSCSI)
>
>
> As I've already said several times you're welcome to send in a patch to
> change this as well ... as long as you either don't break every other
> driver, or fix them all with the patch.
This is complete FUD and you know it and it is just the political game
you've been playing all this time.
Proof:
1) Any patches submitted to lsml, you change and then you resubmit
yourself, unless of course they come in from a few "chosen" people.
I.e. people who do not challenge your antics.
This _policy_ disourages people from actually doing any new and
innovative work with SCSI Core.
2) You are well aware that NONE of SCSI Core is relevant as it stands
today for a new, SAM/SPC abiding architecture like SAS. You know very
well that other than LUN scanning and some SAM/SPC tasks, one needs
very little to support SAS.
3) Your own effort on this (converting LUN to "u64") failed:
http://marc.10east.com/?l=linux-scsi&m=112664309529813&w=2
YET, you try to keep this semantically fat, overloaded with lots of
little quirks for old hardware, SCSI Core.
You have to let things in, so that they can evolve naturally.
You cannot give heart attack to 50 or so LLDDs.
> You were given a step by step
> procedure at least for the I replacement piece.
How many times do I have to tell you that this was Christoph's
reply to an email of mine _asking_ me if this were the way to do it?
And then I told him that it is not quite the way to do it?
See this link:
http://marc.theaimsgroup.com/?l=linux-scsi&m=112507133514575&w=2
> The only power of a maintainer is to say "no". So, although I cannot
> make you fix any of the problems in your submission, I can say no until
> an acceptable submission comes along for this driver.
You see, you and I do not see eye to eye, since we do not have the same
base: T10.org.
I read books, specs, drafts, firmware, code, presentations, lectures,
etc. It isn't easy, but necessary to do my job better and better every
day. It is necessary so that I'm knowlegable and can provide immediate
response and help when asked to.
So I'm not sure about your point of view. SCSI 20 years ago?
I'm not sure what kind of convicing it would take?
Maybe we can do a presentation in front of an audience of _storage_
folks? We can both explain out points of view.
> At this point, I
> believe all the technical issues of what needs to happen are well
> understood;
Nah. You're just saying this to manipulate the readers of this
thread. Or maybe those "needs" are well understoood _in your head_
only? I told you before: be _specific_.
What needs improvement is NOT the SAS Transport Layer and/or
aic94xx LLDDs.
What needs improvement, in order to _better_ _accomodate_
_new_ technologies is SCSI Core. If not even a new SCSI Core
developed in parallel (so the old one can be config-not-compile
if one has no legacy controllers and devices and vice-versa).
SCSI Core is 20 years _behind_. And thus _Linux_ SCSI
is 20 years behind. Apparently no one cares.
When you get your new shiny mainboard with an AIC-94xx
chip on it (check with SuperMicro), which can handle SAS and SATA,
you do not need to compile this fat, old and semantically broken
SCSI Core, but a smaller, faster one.
> I also believe that this is an important enough piece of
Since when do you think it is important? This is the first
time you're saying this and I think someone was talking to
you. XYZ?
> hardware that an acceptable driver will come along even if you want to
> play dog in the manger, so all I can do is wait.
So what you're saying is "my way or the highway"?
"all I can do is wait"?
James, why not just simply move out of the way?
Instead of you _waiting_ and thus do nothing, you can
move out of the way, or listen and accept _technical_ advice.
This is unfortunate. History shows us that being
inflexible to new ideas (or technologies) becomes
one's undoing.
I wonder if SCSI Core could be Linux's undoing? Could this
and reiser4, and OBDs (yet another new SCSI technology in the
making), show us how inflexible Linux has become?
Now its SAS and reiser4. When OBDs come out full force it
will be the block layer, then who knows whatelse...
Is Linux going to be just as obstinate?
Why has Linux become like this?
Luben
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |
