Hi Linus,
I request inclusion of the SAS Transport Layer
and the AIC-94xx SAS LLDD into the Linux kernel.
Please find your latest git tree with SAS
Transport Layer and AIC-94xx, patches and
a whole tar.bz2 tree here:
http://linux.adaptec.com/sas/
There you will also find the original announcements
posted to this list.
The code is updated twice daily or more often as
needed.
Thank you,
Luben
P.S. This is a second resend of an identical message
I posted to lkml and lsml yesterday.
On Tue, Sep 27, 2005 at 09:07:24AM -0400, Luben Tuikov wrote:
> P.S. This is a second resend of an identical message
> I posted to lkml and lsml yesterday.
And it's not gotten anymore includable. Please fix the major structural
issues pointed out when you first sent it out. That's in the following
order:
- not trying to integrate with the sas transport class in Linus'
tree at all, not even using the transport class infrastructure
at all, creating it's own sysfs trees in rather wierd ways
- not beeing structures as a library (ala libata which is a very good
model for it)
- duplicating the lun scanning code instead of using the scsi core one
On 09/27/05 09:19, Christoph Hellwig wrote:
> On Tue, Sep 27, 2005 at 09:07:24AM -0400, Luben Tuikov wrote:
>
>>P.S. This is a second resend of an identical message
>>I posted to lkml and lsml yesterday.
>
>
> And it's not gotten anymore includable. Please fix the major structural
Major?
Christoph, why diseminate FUD, when we can concentrate on the
_technical_ merits of SCSI and SAS instead?
Why talk non-constructive things, when we can have a SCSI Storage
discussion?
> issues pointed out when you first sent it out. That's in the following
> order:
>
> - not trying to integrate with the sas transport class in Linus'
Well here we go _again_:
The SAS Transport Class (your an JB's incarnation) is _not_
a management infrastructure, it was _never_ _intended_ to be.
The whole point of it is to _export_ *attributes* of MPT-technology
like drivers. All those drivers that it caters to _do_ _not_ need a
_management_ layer (Discovery, Expander configuration, etc.).
They "export" SCSI LUs directly to SCSI Core through their LLDDs.
If you cared to read any of the "techno-babble" (as you call it)
documents and specs you'd clearly see how and _why_ it fits
with a SCSI Stack. As baby food, see this _picture_:
http://www.t10.org/scsi-3.gif
For an adult meal, maybe some reading of "techno-babble"
would help?
> tree at all, not even using the transport class infrastructure
> at all, creating it's own sysfs trees in rather wierd ways
"weird ways" ? Did you care to see what a SAS domain looks like?
There is plenty of references, slides, course notes, etc on the
Internet.
Christoph, I work with this technology every day. OTOH, you
blocked LSI's drivers from going in until they sent you hardware
just a month ago.
What you see in sysfs is _exactly_ what you'd see in the _physical_
world, _including_ the "locking" -- i.e. the "kobject_get". It "locks"
object which are needed for the command to travel to, in _actuallity_.
If you say that it is "weird" then you are also saying that
a SAS Domain in the *physical* world is weird.
It is the _natural_ representation of the SAS domain.
What seems "weird" to you, is what it _actually_ is.
This is what this new technology is. You can learn it
or you can call it "weird" and "techno-babble", and invent
your own understanding of SAS and shove it down the throat
of thousands of Linux users and vendors.
> - not beeing structures as a library (ala libata which is a very good
> model for it)
It _cannot_ be presented as a library, because _again_ it is a
*management layer*, an infrastructure.
What it manages is, _again_ to repeat myself, SAS objects:
ports, connections, devices, discovery, expander management, etc.
See the original Announcement 0 here, it explains this in detail:
http://marc.theaimsgroup.com/?l=linux-scsi&m=112629423714248&w=2
> - duplicating the lun scanning code instead of using the scsi core one
The LUN scanning code is, uum, how to say this nicely... wrong?
It did its job for Parallel SCSI and for broken arrays who do not
respond to REPORT LUNS, but have a bunch of disks behind, but it is
wrong _by design_ and it is _not_ _relevant_ in SAS. To properly see
how LUN scanning is done, look at sas_discover.c.
SCSI Core does not know about everyday SCSI objects like a "SCSI
Device with a Target port". It does things backwarads _and_ foremost
of all, it uses _HCIL_.
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)
Christoph, SCSI Core is 20 years behind.
I appreciate your aggresiveness and JB's political games,
but what it comes down to, Linux SCSI, vendors, users, and
its _other_ developers suffer.
Anyway, when all you have is an AIC-94xx or BCM8603 chip on your
mainboard (check with SuperMicro) you *do not need* the semantically
fat, broken and wrong SCSI Core (catering to old, outdated, broken
SPI machines).
You need a _minimal_ SCSI Core, SAM/SPC-like, when you have a new
technology like SAS and _none_ of the semantically fat and broken
SCSI Core is _relevant_ in a SAS world.
Christoph how long are you and James Bottomley going to hold
SCSI Core _hostage_ to new technologies?
How long are you going to _block_ SCSI storage innovation
from the Linux kernel?
Or is this the new way of embezzling hardware from vendors?
Is this what is done in the other Linux kernel subsystems?
I don't get it. If you or James Bottomley think that
- LUNS can be represented as "u64", and
- sending REQUEST SENSE clears ACA,
- "SCSI Device with Target port" is "techno-babble",
how can you drive new SCSI technology?
Someone please pinch me, because I'm dreaming this horrible
nightmare.
Luben
On Tue, 2005-09-27 at 11:01 -0400, Luben Tuikov wrote:
> On 09/27/05 09:19, Christoph Hellwig wrote:
> > On Tue, Sep 27, 2005 at 09:07:24AM -0400, Luben Tuikov wrote:
> >
> >>P.S. This is a second resend of an identical message
> >>I posted to lkml and lsml yesterday.
> >
> >
> > And it's not gotten anymore includable. Please fix the major structural
> 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
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.
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.
> Why talk non-constructive things, when we can have a SCSI Storage
> discussion?
>
> > issues pointed out when you first sent it out. That's in the following
> > order:
> >
> > - not trying to integrate with the sas transport class in Linus'
>
> Well here we go _again_:
>
> The SAS Transport Class (your an JB's incarnation) is _not_
> a management infrastructure, it was _never_ _intended_ to be.
Actually, it was intended to be such. The sysfs components of the
transport class are the unified management interface to the transport.
> The whole point of it is to _export_ *attributes* of MPT-technology
> like drivers. All those drivers that it caters to _do_ _not_ need a
> _management_ layer (Discovery, Expander configuration, etc.).
> They "export" SCSI LUs directly to SCSI Core through their LLDDs.
No, the point of a transport class is to export the underlying
attributes of the actual devices that are present. This is supposed to
be independent of the driver used to connect to them (and that's what
your sas class breaks).
> > - duplicating the lun scanning code instead of using the scsi core one
>
> The LUN scanning code is, uum, how to say this nicely... wrong?
> It did its job for Parallel SCSI and for broken arrays who do not
> respond to REPORT LUNS, but have a bunch of disks behind, but it is
> wrong _by design_ and it is _not_ _relevant_ in SAS. To properly see
> how LUN scanning is done, look at sas_discover.c.
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
you of why scsi_scan_target can't work for sas_discover).
> 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. You were given a step by step
procedure at least for the I replacement piece.
> Christoph how long are you and James Bottomley going to hold
> SCSI Core _hostage_ to new technologies?
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. At this point, I
believe all the technical issues of what needs to happen are well
understood; I also believe that this is an important enough piece of
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.
James
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
Luben Tuikov wrote:
> 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,
The fact that your responses are constantly filled with non-technical
paranoia does not help the inclusion of aic94xx at all.
Maybe you need to write your driver as a block driver, and completely
skip the SCSI core, if it bothers you so much? That would get everybody
else out of the loop, and free you to write the driver as you see fit.
As it stands now, you're making an end run around the SCSI core, rather
than fixing it up. SCSI needs to be modified for SAS, not just
complained about.
Jeff
On 09/27/05 16:34, Jeff Garzik wrote:
> Luben,
>
> The fact that your responses are constantly filled with non-technical
> paranoia does not help the inclusion of aic94xx at all.
>
> Maybe you need to write your driver as a block driver, and completely
> skip the SCSI core, if it bothers you so much? That would get everybody
> else out of the loop, and free you to write the driver as you see fit.
Hi Jeff, how are you doing?
Yes, that has been suggested before. But do you remember what
happened when I posted a patch to IDR? James moved from SCSI Core
to IDR. hehehe ;-)
In the mids of the FUD, I completely removed IDR from being used
in aic94xx, long before I posted the driver.
> As it stands now, you're making an end run around the SCSI core, rather
> than fixing it up. SCSI needs to be modified for SAS, not just
> complained about.
Well, back in 2001-2 I was asking for 64 bit LUN support and
for native SCSI target support (since iSCSI "exports" targets), and
it uses 64 bit LUNs (as any other transport). Both sniffed at
and rejected by your friends.
See this thread from me, all the way back in 2002:
http://marc.theaimsgroup.com/?l=linux-scsi&m=103013448713434&w=2
You still have people from IBM who claim that 64 bit LUN
support is completely unnecessary as recently as 2 weeks ago.
(link to email on marc.10east.com available upon request)
As it has come to now, 2005, we cannot afford any more "putting off".
The driver and the infrastructure needs to go in.
Give it exposure to the people, let people play with it.
If we start "fixing" SCSI Core now (this in itself is JB red
herring), how long before it is "fixed" and we can "rest"?
And how long then before the driver and infrastructure
makes it in?
"How long is the long hair?"
You are calling for fixing SCSI Core. JB is calling for
integrating MPT with open transport. I'm sure people
have other (crazy) requests.
At the end of the day the driver is not in, and business
suffers. And its not like the driver is using
static struct file_operations megasas_mgmt_fops, ;-)
IOCTLs or other char dev for management...
The driver does _not_ alter anything in the kernel, it only
integrates with it.
There needs to be a "passing gate":
Linus, let the driver and transport layer in, as is and then
patches "fixing SCSI Core" would start coming, naturally.
>From people, from me, from everybody.
Luben
Luben Tuikov wrote:
> The driver and the infrastructure needs to go in.
>
> Give it exposure to the people, let people play with it.
Merging into the upstream kernel is not necessary for exposure.
Historically, saying "no" to a single vendor pushing really hard -- as
you are doing -- has resulted in a superior solution.
> If we start "fixing" SCSI Core now (this in itself is JB red
> herring), how long before it is "fixed" and we can "rest"?
> And how long then before the driver and infrastructure
> makes it in?
Just follow the recipe Christoph outlined. It's not difficult, just
requires some work.
> At the end of the day the driver is not in, and business
> suffers. And its not like the driver is using
> static struct file_operations megasas_mgmt_fops, ;-)
> IOCTLs or other char dev for management...
>
> The driver does _not_ alter anything in the kernel, it only
> integrates with it.
>
> There needs to be a "passing gate":
> Linus, let the driver and transport layer in, as is and then
> patches "fixing SCSI Core" would start coming, naturally.
>>From people, from me, from everybody.
So far, this is an Adaptec-only solution.
It does an end run around 90% of the SCSI core. You might as well make
it a block driver, if you're going to do that.
Jeff
On 09/27/05 18:01, Jeff Garzik wrote:
> Luben Tuikov wrote:
>
>>The driver and the infrastructure needs to go in.
>>
>>Give it exposure to the people, let people play with it.
>
>
> Merging into the upstream kernel is not necessary for exposure.
>
> Historically, saying "no" to a single vendor pushing really hard -- as
> you are doing -- has resulted in a superior solution.
This of course implies that everything in Linux is a
superiour solution _or_ if it is not, then everything in
linux is a vendor solution.
>>If we start "fixing" SCSI Core now (this in itself is JB red
>>herring), how long before it is "fixed" and we can "rest"?
>>And how long then before the driver and infrastructure
>>makes it in?
>
> Just follow the recipe Christoph outlined. It's not difficult, just
> requires some work.
Anyone have a clear technical plan and/or infrastructure
on how to do this? Any specs, plans, consolidations, etc?
I know its a wishful thinking, but when the architectures
differ, not sure how to do this.
"You can do everything with a big long if ()".
> So far, this is an Adaptec-only solution.
Yes, since Adaptec is the first company to come out with
open transport SAS chip. Broadcom seems to be doing the same thing.
> It does an end run around 90% of the SCSI core. You might as well make
> it a block driver, if you're going to do that.
The "90%" part isn't quite true.
But going with a block device isn't that bad:
Now since the architecture _is_ SCSI after all, what would be
needed is a minimal, fast, straightforward, SAM/SPC fully complient
new SCSI Core. That SCSI Core would register block devices
with the block layer. Maybe Jens can point out cool things
to do and make the whole infrastructure fast and very fast.
(since we don't need to be bound by this legacy stuff)
Essentially other new technology LLDD and Transport layers
can probably make use of this: Infiniband, USB2 Storage, etc.
So if all you have is an AIC-94xx or BCM8603 storage chip
you can exclule all of the legacy SCSI Core and compile this
new mean, lean, fast SAM Core.
Jeff, this isn't bad at all!
Are you willing to contribute to such an effort?
Thanks,
Luben
On Tue, 2005-09-27 at 19:03 -0400, Luben Tuikov wrote:
> On 09/27/05 18:01, Jeff Garzik wrote:
> > Luben Tuikov wrote:
> >
> >>The driver and the infrastructure needs to go in.
> >>
> >>Give it exposure to the people, let people play with it.
> >
> >
> > Merging into the upstream kernel is not necessary for exposure.
> >
> > Historically, saying "no" to a single vendor pushing really hard -- as
> > you are doing -- has resulted in a superior solution.
>
> This of course implies that everything in Linux is a
> superiour solution _or_ if it is not, then everything in
> linux is a vendor solution.
Or perhaps that it tends to result in better solutions than what would
exist if every vendor wrote their drivers with no consideration for
other vendors.
>
> >>If we start "fixing" SCSI Core now (this in itself is JB red
> >>herring), how long before it is "fixed" and we can "rest"?
> >>And how long then before the driver and infrastructure
> >>makes it in?
> >
> > Just follow the recipe Christoph outlined. It's not difficult, just
> > requires some work.
>
> Anyone have a clear technical plan and/or infrastructure
> on how to do this? Any specs, plans, consolidations, etc?
>
> I know its a wishful thinking, but when the architectures
> differ, not sure how to do this.
> "You can do everything with a big long if ()".
This sounds equivalent to "write your own block driver".
>
> > So far, this is an Adaptec-only solution.
>
> Yes, since Adaptec is the first company to come out with
> open transport SAS chip. Broadcom seems to be doing the same thing.
>
> > It does an end run around 90% of the SCSI core. You might as well make
> > it a block driver, if you're going to do that.
>
> The "90%" part isn't quite true.
>
> But going with a block device isn't that bad:
> Now since the architecture _is_ SCSI after all, what would be
> needed is a minimal, fast, straightforward, SAM/SPC fully complient
> new SCSI Core. That SCSI Core would register block devices
> with the block layer. Maybe Jens can point out cool things
> to do and make the whole infrastructure fast and very fast.
> (since we don't need to be bound by this legacy stuff)
Except that you would have to re-implement the SCSI upper-layer drivers
(at a minimum). Seems like it would be easier to take the existing code
in your driver/layers and modify to work with the existing SCSI
infrastructure.
>
> Essentially other new technology LLDD and Transport layers
> can probably make use of this: Infiniband, USB2 Storage, etc.
>
Seems silly to have all this code duplication. Why not write to the
existing spec (even if it is an informal one), and then work to get the
spec changed, hopefully without pissing off all the maintainers.
> So if all you have is an AIC-94xx or BCM8603 storage chip
> you can exclule all of the legacy SCSI Core and compile this
> new mean, lean, fast SAM Core.
>
> Jeff, this isn't bad at all!
I am not sure if Jeff meant this as a tongue-in-cheek suggestion or is
just trying to get you off peoples backs. Perhaps he is indeed
serious.
Andrew
>
> Are you willing to contribute to such an effort?
>
> Thanks,
> Luben
>
Luben Tuikov wrote:
> On 09/27/05 18:01, Jeff Garzik wrote:
>>Just follow the recipe Christoph outlined. It's not difficult, just
>>requires some work.
>
>
> Anyone have a clear technical plan and/or infrastructure
> on how to do this? Any specs, plans, consolidations, etc?
Yes, read Christoph's todo list.
We need to separate out bits specific to parallel SCSI, moving the bits
to transport-specific code, since SAS doesn't need them.
>>It does an end run around 90% of the SCSI core. You might as well make
>>it a block driver, if you're going to do that.
>
>
> The "90%" part isn't quite true.
>
> But going with a block device isn't that bad:
> Now since the architecture _is_ SCSI after all, what would be
> needed is a minimal, fast, straightforward, SAM/SPC fully complient
> new SCSI Core. That SCSI Core would register block devices
> with the block layer. Maybe Jens can point out cool things
> to do and make the whole infrastructure fast and very fast.
> (since we don't need to be bound by this legacy stuff)
>
> Essentially other new technology LLDD and Transport layers
> can probably make use of this: Infiniband, USB2 Storage, etc.
>
> So if all you have is an AIC-94xx or BCM8603 storage chip
> you can exclule all of the legacy SCSI Core and compile this
> new mean, lean, fast SAM Core.
>
> Jeff, this isn't bad at all!
>
> Are you willing to contribute to such an effort?
No. I'm much more willing to help integrate aic94xx and
Broadcom/ServerWorks into the existing SCSI core, working with the
community.
As Andrew guessed, it's a way to get you your own playpen, where you
won't be constrained by members of the Linux-SCSI community.
Jeff
Warning: philosophical thread hijack ahead ;)
> A scientific theory is an approximation of observed behaviour
> WITH NO KNOWN HOLES.
This has nothing to do with the topic at hand, but it is a pet peeve of
mine. Sorry for hijacking a thread.
The above is a good one sentence approximation of what a theory is in
science, but it's not correct. The classic example, of course, is
quantum mechanics, which is a very good theory, and has the glaring
notorious hole of lacking an explanation for gravity.
>
> Once there are known holes in the theory, it's not a
> scientific theory. At best it's an approximation, but quite
> possibly it's just plain wrong.
>
Alas, the difference between theory and practice is much larger in
practice. Most scientific theories have known holes in them. Not
always as glaring as the lack of quantum gravity, but always present.
There are even well documented cases where the theory was not supported
by the observations, so the observations were, eventually, redone, only
to determine that they were done wrong in the first place; so it's not
even as simple as 'must agree with reality'.
Science, once you lift the lid is a very messy endevour.
> And that's my point. Specs are not only almost invariably
> badly written, they also never actually match reality.
Ooops. I'm going to have to go back on topic here. I think that a
large part of this debate over specs is due to looking at two different
aspects of specs. I have often worked in a world where specs were very
accurate, and kept current with reality. This is the world in which
specs are the basis for new things. When it works, it works very well.
Most of us, though, are living in the world of finished devices. The
problem in our world is that specs are allowed to bit-rot. Architects,
when they care a lot about their work, maintain two sets of plans, the
'as designed' plans and the 'as built' plans. We in the computer
industry, for a lot of reasons, tend not to maintain the 'as built'
plans.
> So don't talk about specs.
Unfortunately, even in our imperfect world of imperfect specs, we still
need them. Rather than 'don't talk about specs', in the real world, we
have to deal with 'here's a spec, add a grain of salt'. You don't get
interoperability without that, and you don't get code portability
without it either.
>
> Talk about working code that is _readable_ and _works_.
>
Once upon a time, we converted an (unnamed) fortune 500 company's C
compiler from vendor X to vendor Y. As head of the OS team, I
volunteered our kernel as a test ap. Eventually, we found a very
readable implementation of select that, unfortunately, was utterly
busted C code. "luckily", the old compiler had a bug in it that caused
it to generate working code for the utterly busted C code.
Needless to say that reality and the spec differed in this case.
And we fixed reality to match the spec.
> There's an absolutely mindbogglingly huge difference between the two.
>
Yes. "Be pragmatic about specs" is very good advice. "Ignore specs" is
a recipe for anarchy. ;)
We now return your thread to its regularly scheduled debate.
Linus Torvalds <[email protected]> writes:
> On Wed, 28 Sep 2005, Matthew Wilcox wrote:
>>
>> Dude, that document is written in a very tongue-in-cheek style.
>
> True, true. But sometimes you can say painful truths more easily if you do
> it as a joke. Most of the ManagementStyle document is perfectly valid.
Yes, I thought I understood it when I read it first, but I later
realized that my understanding was very superficial.
When I re-read it now, I cannot help chuckling, remembering how
you kept saying "go wild", "make it so", "That is good, but it
strikes me that there is no fundamental reason to limit
ourselves to ..." on the git list ;-).
At the SAS BOF, I indicated that it would not be much trouble to
translate the CSMI handler in the aacraid driver to a similar sysfs
arrangement. If such info can be mined from a firmware based RAID card,
every driver should be able to do so. The spec writers really need to
consider rewriting SDI for sysfs (if they have not already) and move
away from an ABI.
Sincerely -- Mark Salyzyn
-----Original Message-----
From: Tuikov, Luben
Sent: Friday, September 30, 2005 12:47 PM
To: [email protected]
Cc: [email protected]; Linus Torvalds; Luben Tuikov; SCSI Mailing List;
Linux Kernel Mailing List
Subject: Re: I request inclusion of SAS Transport Layer and AIC-94xx
into the kernel
On 09/30/05 12:26, Andrew Patterson wrote:
>
> I talked to one of the authors of these specs. SDI is an attempt to
> create an open standard for the somewhat proprietary CSMI spec
> developed by HP. It is currently languishing in t10 due to the IOCTL
> problem you describe below (the "no new IOCTL's" doctrine caught them
> by surprise). There is some thought to going to a write()/read() on a
> character device model, but this has various problems as well.
I think that read/write from a char device is going away too.
For this reason I showed the whole picture of the SAS
domain in sysfs _and_ created a binary file attr to send/receive SMP
requests/responses to control the domain and get attributes
("smp_portal" binary attr of each expander).
It is completely user space driven and a user space library
is simple to write.
See drivers/scsi/sas/expander_conf.c which is a user
space utility. For the output see Announcement 3:
http://linux.adaptec.com/sas/Announce_2.txt or here:
http://marc.theaimsgroup.com/?l=linux-scsi&m=112629509318354&w=2
The code which implements it is very tiny, at the bottom
of drivers/scsi/sas/sas_expander.c
On Fri, 2005-09-30 at 13:07 -0400, Salyzyn, Mark wrote:
> At the SAS BOF, I indicated that it would not be much trouble to
> translate the CSMI handler in the aacraid driver to a similar sysfs
> arrangement. If such info can be mined from a firmware based RAID card,
> every driver should be able to do so. The spec writers really need to
> consider rewriting SDI for sysfs (if they have not already) and move
> away from an ABI.
that makes me wonder... why and how does T10 control linux abi's ??
On Fri, 2005-09-30 at 13:07 -0400, Salyzyn, Mark wrote:
> At the SAS BOF, I indicated that it would not be much trouble to
> translate the CSMI handler in the aacraid driver to a similar sysfs
> arrangement. If such info can be mined from a firmware based RAID card,
> every driver should be able to do so. The spec writers really need to
> consider rewriting SDI for sysfs (if they have not already) and move
> away from an ABI.
SDI is supposed to be a cross-platform spec, so mandating sysfs would
not work. I suggested to the author to use a library like HPAAPI (used
by Fibre channel), so you could hide OS implementation details. I am in
fact working on such a beasty (http://libsdi.berlios.de). He thinks
that library solutions tend to not work, because the library version is
never in synch with the standard/LLDD's. Given Linux vendor lead-times,
he does have a valid point.
Note that a sysfs implementation has problems. Binary attributes are
discouraged/not-allowed. There is no atomic request/response
operations, buffers limited to page size, etc. Other alternatives are
configfs, SG_IO, and the above mentioned character device. None are a
complete replacement for the transactional nature of IOCTL's. A group
of us are looking into this. We probably should be taking it to
linux-scsi, but didn't want to get it caught up in the current flamewar.
Andrew
>
> Sincerely -- Mark Salyzyn
>
> -----Original Message-----
> From: Tuikov, Luben
> Sent: Friday, September 30, 2005 12:47 PM
> To: [email protected]
> Cc: [email protected]; Linus Torvalds; Luben Tuikov; SCSI Mailing List;
> Linux Kernel Mailing List
> Subject: Re: I request inclusion of SAS Transport Layer and AIC-94xx
> into the kernel
>
> On 09/30/05 12:26, Andrew Patterson wrote:
> >
> > I talked to one of the authors of these specs. SDI is an attempt to
> > create an open standard for the somewhat proprietary CSMI spec
> > developed by HP. It is currently languishing in t10 due to the IOCTL
> > problem you describe below (the "no new IOCTL's" doctrine caught them
> > by surprise). There is some thought to going to a write()/read() on a
> > character device model, but this has various problems as well.
>
> I think that read/write from a char device is going away too.
>
> For this reason I showed the whole picture of the SAS
> domain in sysfs _and_ created a binary file attr to send/receive SMP
> requests/responses to control the domain and get attributes
> ("smp_portal" binary attr of each expander).
>
> It is completely user space driven and a user space library
> is simple to write.
>
> See drivers/scsi/sas/expander_conf.c which is a user
> space utility. For the output see Announcement 3:
> http://linux.adaptec.com/sas/Announce_2.txt or here:
> http://marc.theaimsgroup.com/?l=linux-scsi&m=112629509318354&w=2
>
> The code which implements it is very tiny, at the bottom
> of drivers/scsi/sas/sas_expander.c
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
On 09/30/05 14:39, Andrew Patterson wrote:
>
> SDI is supposed to be a cross-platform spec, so mandating sysfs would
> not work.
True, sysfs is a Linux only thing.
But you can write a user space library which uses sysfs or whatever
_that_ OS uses to represent an SDI spec-ed out picture.
So a user space program would call (uniformly across all OSs)
a libsdi library which will use whatever OS dependent way there is
to get the information (be it sysfs or ioctl).
> I suggested to the author to use a library like HPAAPI (used
> by Fibre channel), so you could hide OS implementation details. I am in
> fact working on such a beasty (http://libsdi.berlios.de). He thinks
> that library solutions tend to not work, because the library version is
> never in synch with the standard/LLDD's. Given Linux vendor lead-times,
> he does have a valid point.
Yes, but it would be the best of all the current ways there are
to do it.
> Note that a sysfs implementation has problems. Binary attributes are
> discouraged/not-allowed.
I've never heard that. Is this similar to the argument
"The sysfs tree would be too deep?"
> There is no atomic request/response operations
For a reason: let user space do it, there is plenty of ways to
do it, some assisted by the kernel.
> buffers limited to page size, etc.
"You have an attribute larger than 4k? What is it?"
As to SMP response/request is more than 4K/8K? The largest
I'm aware of is 64 bytes.
> Other alternatives are
> configfs, SG_IO, and the above mentioned character device. None are a
Again, char devices for controlling are discouraged. There are not enough
around and it is old technology.
> complete replacement for the transactional nature of IOCTL's. A group
Here:
/* User space lock */
fd = open(smp_portal, ...);
write(fd, smp_req, smp_req_size);
read(fd, smp_resp, smp_resp_size);
close(fd);
/* User space unlock */
Luben
On Fri, 2005-09-30 at 15:21 -0400, Luben Tuikov wrote:
> On 09/30/05 14:39, Andrew Patterson wrote:
> >
> > SDI is supposed to be a cross-platform spec, so mandating sysfs would
> > not work.
>
> True, sysfs is a Linux only thing.
>
> But you can write a user space library which uses sysfs or whatever
> _that_ OS uses to represent an SDI spec-ed out picture.
Yes you can, which is what I am trying to do. However, is that library
also available on Solaris and Windows? Is it up to date? These are the
reasons why the spec authors rejected that approach. I don't agree with
them BTW, but I do understand why they think that way.
>
> So a user space program would call (uniformly across all OSs)
> a libsdi library which will use whatever OS dependent way there is
> to get the information (be it sysfs or ioctl).
See the paragraph below.
>
> > I suggested to the author to use a library like HPAAPI (used
> > by Fibre channel), so you could hide OS implementation details. I am in
> > fact working on such a beasty (http://libsdi.berlios.de). He thinks
> > that library solutions tend to not work, because the library version is
> > never in synch with the standard/LLDD's. Given Linux vendor lead-times,
> > he does have a valid point.
>
> Yes, but it would be the best of all the current ways there are
> to do it.
Theoretically yes. Practically, perhaps not. The authors seem to have
been left with a bad taste in their mouths after their experience with
HBA API. They agree that IOCTL are bad too do to lack of linux support,
but do not have a better cross-platform solution as yet. The current
way around this is to use CSMI and brow-beat various Linux vendors into
allowing these IOCTL's into their kernels.
>
> > Note that a sysfs implementation has problems. Binary attributes are
> > discouraged/not-allowed.
>
> I've never heard that. Is this similar to the argument
> "The sysfs tree would be too deep?"
>From Documentation/filesystes/sysfs.txt
"Attributes should be ASCII text files, preferably with only one value
per file. It is noted that it may not be efficient to contain only
value per file, so it is socially acceptable to express an array of
values of the same type.
Mixing types, expressing multiple lines of data, and doing fancy
formatting of data is heavily frowned upon. Doing these things may get
you publically humiliated and your code rewritten without notice."
My understanding is that sysfs is meant to be human-readable. I do not
know if this is a hard and fast rule or just a convention. Configfs is
probably a better fit at least for writeable attributes, but may not be
cooked yet.
>
> > There is no atomic request/response operations
>
> For a reason: let user space do it, there is plenty of ways to
> do it, some assisted by the kernel.
User space locking can only guarantee atomic operations in user space.
>
> > buffers limited to page size, etc.
>
> "You have an attribute larger than 4k? What is it?"
Not sure at the moment, can I guarantee this for the future?
>
> As to SMP response/request is more than 4K/8K? The largest
> I'm aware of is 64 bytes.
>
> > Other alternatives are
> > configfs, SG_IO, and the above mentioned character device. None are a
>
> Again, char devices for controlling are discouraged. There are not enough
> around and it is old technology.
There are as many as one would want. We now have 32 bit device numbers.
Old technology is fine as long as it works, especially if their is no
new technology to replace it. Note that I don't like the character
device solution either. What would really be nice is something that will
allow us to pass an arbitrary request buffer, and get an arbitrary
response buffer back in a single transaction, SG_IO comes closest, but
shares request/response buffers and is limited to a 16-byte commands.
It also requires a device file.
>
> > complete replacement for the transactional nature of IOCTL's. A group
>
> Here:
>
> /* User space lock */
>
> fd = open(smp_portal, ...);
> write(fd, smp_req, smp_req_size);
> read(fd, smp_resp, smp_resp_size);
> close(fd);
>
> /* User space unlock */
>
See above. This stuff works for trivial user-space apps. It will not
suffice for most storage management apps.
Andrew
> Luben
>
On Fri, Sep 30, 2005 at 02:14:50PM -0600, Andrew Patterson wrote:
> > > Note that a sysfs implementation has problems. Binary attributes are
> > > discouraged/not-allowed.
> >
> > I've never heard that. Is this similar to the argument
> > "The sysfs tree would be too deep?"
>
> >From Documentation/filesystes/sysfs.txt
>
> "Attributes should be ASCII text files, preferably with only one value
> per file. It is noted that it may not be efficient to contain only
> value per file, so it is socially acceptable to express an array of
> values of the same type.
>
> Mixing types, expressing multiple lines of data, and doing fancy
> formatting of data is heavily frowned upon. Doing these things may get
> you publically humiliated and your code rewritten without notice."
>
> My understanding is that sysfs is meant to be human-readable. I do not
> know if this is a hard and fast rule or just a convention. Configfs is
> probably a better fit at least for writeable attributes, but may not be
> cooked yet.
There's precedent for binary data in sysfs -- pci config space is one.
On 09/30/05 16:14, Andrew Patterson wrote:
>
> Yes you can, which is what I am trying to do. However, is that library
> also available on Solaris and Windows? Is it up to date? These are the
Is the kernel the latest one? Is it up to date?
See? Same argument.
>>>Note that a sysfs implementation has problems. Binary attributes are
>>>discouraged/not-allowed.
>>
>>I've never heard that. Is this similar to the argument
>>"The sysfs tree would be too deep?"
>
>
>>From Documentation/filesystes/sysfs.txt
>
> "Attributes should be ASCII text files, preferably with only one value
> per file. It is noted that it may not be efficient to contain only
> value per file, so it is socially acceptable to express an array of
> values of the same type.
>
> Mixing types, expressing multiple lines of data, and doing fancy
> formatting of data is heavily frowned upon. Doing these things may get
> you publically humiliated and your code rewritten without notice."
I see this talk _only_ about non-binary attributes.
Plus you have to admit: the SAS sysfs "smp_portal" binary
attribute is very versatile: you completely control the
expander from user space _if_ you can see it: It is
almost like "point and click".
I imagine there would be GUIs built on top of it, which would
actually implement that "point, click, control".
> My understanding is that sysfs is meant to be human-readable. I do not
But `cat /sysfs/.../smp_portal` _is_ human readable. See? Its size is
0 bytes and when you read it you get 0 data read.
> User space locking can only guarantee atomic operations in user space.
And user space is the whole audience of this interface.
> Not sure at the moment, can I guarantee this for the future?
How far in the future? 1, 3, 6 months? 1, 3, 6 years?
Plus if you need an attribute larger than 4K, you've got
other problems to worry about.
> There are as many as one would want. We now have 32 bit device numbers.
> Old technology is fine as long as it works, especially if their is no
> new technology to replace it. Note that I don't like the character
> device solution either. What would really be nice is something that will
> allow us to pass an arbitrary request buffer, and get an arbitrary
> response buffer back in a single transaction,
Here:
/* User space lock */
fd = open(smp_portal, ...);
write(fd, smp_req, smp_req_size);
read(fd, smp_resp, smp_resp_size);
close(fd);
/* User space unlock */
> See above. This stuff works for trivial user-space apps. It will not
> suffice for most storage management apps.
Sorry but I completely fail to see this argument.
How will it "fail for most storage managament apps"?
Luben
On Fri, 2005-09-30 at 16:32 -0400, Luben Tuikov wrote:
> On 09/30/05 16:14, Andrew Patterson wrote:
> >
> > Yes you can, which is what I am trying to do. However, is that library
> > also available on Solaris and Windows? Is it up to date? These are the
>
> Is the kernel the latest one? Is it up to date?
>
> See? Same argument.
>
> >>>Note that a sysfs implementation has problems. Binary attributes are
> >>>discouraged/not-allowed.
> >>
> >>I've never heard that. Is this similar to the argument
> >>"The sysfs tree would be too deep?"
> >
> >
> >>From Documentation/filesystes/sysfs.txt
> >
> > "Attributes should be ASCII text files, preferably with only one value
> > per file. It is noted that it may not be efficient to contain only
> > value per file, so it is socially acceptable to express an array of
> > values of the same type.
> >
> > Mixing types, expressing multiple lines of data, and doing fancy
> > formatting of data is heavily frowned upon. Doing these things may get
> > you publically humiliated and your code rewritten without notice."
>
> I see this talk _only_ about non-binary attributes.
I think that "ASCII text files" implies non-binary. As Willy has pointed
out, this has already been violated.
>
> Plus you have to admit: the SAS sysfs "smp_portal" binary
> attribute is very versatile: you completely control the
> expander from user space _if_ you can see it: It is
> almost like "point and click".
No problem with this.
>
> I imagine there would be GUIs built on top of it, which would
> actually implement that "point, click, control".
>
> > My understanding is that sysfs is meant to be human-readable. I do not
>
> But `cat /sysfs/.../smp_portal` _is_ human readable. See? Its size is
> 0 bytes and when you read it you get 0 data read.
I don't quite think your definition of human readable is the same as
mine. I think the intention is to do something like:
$ cat attribute
3 Gb/s
or
$ echo "3 Gb/s" >attribute
Rather than
$ cat attribute
gibberish.
or
$ echo "gibberish" >attribute
But again, this may be just a goal and not a hard and fast rule. I can
definitely see a use for binary attributes in sysfs. Configfs seems to
be designed for this sort of thing.
>
> > User space locking can only guarantee atomic operations in user space.
>
> And user space is the whole audience of this interface.
>
> > Not sure at the moment, can I guarantee this for the future?
>
> How far in the future? 1, 3, 6 months? 1, 3, 6 years?
> Plus if you need an attribute larger than 4K, you've got
> other problems to worry about.
>
> > There are as many as one would want. We now have 32 bit device numbers.
> > Old technology is fine as long as it works, especially if their is no
> > new technology to replace it. Note that I don't like the character
> > device solution either. What would really be nice is something that will
> > allow us to pass an arbitrary request buffer, and get an arbitrary
> > response buffer back in a single transaction,
> , locks it, then hangs.
> Here:
>
> /* User space lock */
>
> fd = open(smp_portal, ...);
> write(fd, smp_req, smp_req_size);
> read(fd, smp_resp, smp_resp_size);
> close(fd);
>
> /* User space unlock */
>
> > See above. This stuff works for trivial user-space apps. It will not
> > suffice for most storage management apps.
>
> Sorry but I completely fail to see this argument., locks it, then hangs.
>
> How will it "fail for most storage managament apps"?
Let's see, one example:
Process A opens an attribute and writes to it. Process B opens another
attribute and writes to it, affecting the result that process A will see
from its subsequent read. I suppose you could lock every attribute, but
that would be very error-prone, and not allow much concurrency.
Andrew
>
> Luben
>
On Fri, Sep 30, 2005 at 03:15:50PM -0600, Andrew Patterson wrote:
> But again, this may be just a goal and not a hard and fast rule. I can
> definitely see a use for binary attributes in sysfs. Configfs seems to
> be designed for this sort of thing.
Configfs is designed for ascii or readable attributes. It drops
the bin_attribute type that sysfs still supports. So if you are looking
to fill a 64K binary attribute, configfs isn't the place you're going to
be going.
> > fd = open(smp_portal, ...);
> > write(fd, smp_req, smp_req_size);
> > read(fd, smp_resp, smp_resp_size);
> > close(fd);
>
> Process A opens an attribute and writes to it. Process B opens another
> attribute and writes to it, affecting the result that process A will see
> from its subsequent read. I suppose you could lock every attribute, but
> that would be very error-prone, and not allow much concurrency.
Check out nfsctl.c and its transaction_file design. process A
and process B get different buffers on filp->f_private, and cannot
influence each other's read/write operations.
Joel
--
Life's Little Instruction Book #347
"Never waste the oppourtunity to tell someone you love them."
Joel Becker
Principal Software Developer
Oracle
E-mail: [email protected]
Phone: (650) 506-8127
On Fri, 30 Sep 2005, Matthew Wilcox wrote:
>
> There's precedent for binary data in sysfs -- pci config space is one.
In general, if the data has no semantic meaning (ie it's just a blob), and
there really is some point to exporting it, it should be exported as a
binary blob. There's no point in doing some random "ASCII conversion" if
the data doesn't have any known semantics. Bytes? Words? Longwords?
Byteorder? It's simply not a sensible operation, and the only sane
interface is to just read a binary blob with the raw data.
That's true in general of PCI config space. Of course, _some_ parts of PCI
config space do indeed have meaning, so you'll find the "device" and
"vendor" and other things like that as separate nodes in /sysfs with ASCII
representations. So sometimes you may have mixtures (but it would be
stupid to try to "remove" the semantic data from the blob - then it would
turn into a _true_ monster).
So it's not like binary blobs are not allowed. In general, the rule should
be:
- all independent values should show up as independent files (never mix
stuff up that you don't need to)
- anything with semantic meaning should have the appropriate semantic
textual format (ie formatted ASCII, not just raw data).
The _goal_ is that you can look at sysfs with a file manager, and the
results should make sense.
Linus
On 09/30/05 17:15, Andrew Patterson wrote:
>>Sorry but I completely fail to see this argument., locks it, then hangs.
>>
>>How will it "fail for most storage managament apps"?
>
>
> Let's see, one example:
>
> Process A opens an attribute and writes to it. Process B opens another
> attribute and writes to it, affecting the result that process A will see
> from its subsequent read. I suppose you could lock every attribute, but
> that would be very error-prone, and not allow much concurrency.
Why should synchronization between Process A and Process B
reading storage attributes take place in the kernel?
They can synchronize in user space.
Luben
Andrew Patterson wrote:
> SDI is supposed to be a cross-platform spec, so mandating sysfs would
> not work. I suggested to the author to use a library like HPAAPI (used
> by Fibre channel), so you could hide OS implementation details. I am in
> fact working on such a beasty (http://libsdi.berlios.de). He thinks
> that library solutions tend to not work, because the library version is
> never in synch with the standard/LLDD's. Given Linux vendor lead-times,
> he does have a valid point.
Any kernel interface lib should be like libc or libalsa: it hides the
kernel details, however nasty they may be, shielding userspace and apps
from various changes over time.
Jeff
Luben Tuikov wrote:
> But you can write a user space library which uses sysfs or whatever
> _that_ OS uses to represent an SDI spec-ed out picture.
>
> So a user space program would call (uniformly across all OSs)
> a libsdi library which will use whatever OS dependent way there is
> to get the information (be it sysfs or ioctl).
Agreed completely :)
Jeff
On 2005-10-01, at 00:01, Luben Tuikov wrote:
> Why should synchronization between Process A and Process B
> reading storage attributes take place in the kernel?
>
> They can synchronize in user space.
In a mandatory and transparent way? How?
On Fri, Sep 30, 2005 at 02:22:34PM -0600, Matthew Wilcox wrote:
> There's precedent for binary data in sysfs -- pci config space is one.
binary data in sysfs is for stuff that is just a "pass through" for the
kernel. Copying the pci config space, in raw form from the device to
userspace is one such example. Firmware blobs is another one.
Binary data in sysfs is _not_ for exporting kernel structures or other
data that the kernel "understands" and manipulates.
Hope this helps,
greg k-h
On Gwe, 2005-09-30 at 19:53 +0200, Arjan van de Ven wrote:
> that makes me wonder... why and how does T10 control linux abi's ??
Indirectly the standards do define APIs at the very least. A good
example is taskfile. ACPI methods (which we don't yet use) allow get/set
mode, get features on the motherboard ATA controller if you don't know
how to drive it. The objects they work in are taskfiles. No taskfiles,
no ACPI.
Alan
On 09/30/05 19:42, Marcin Dalecki wrote:
> On 2005-10-01, at 00:01, Luben Tuikov wrote:
>
>>Why should synchronization between Process A and Process B
>>reading storage attributes take place in the kernel?
>>
>>They can synchronize in user space.
>
>
> In a mandatory and transparent way? How?
Futex, userspace mutex, etc. All through a user
space library interface.
Luben
On 10/01/05 19:55, Alan Cox wrote:
> On Gwe, 2005-09-30 at 19:53 +0200, Arjan van de Ven wrote:
>
>>that makes me wonder... why and how does T10 control linux abi's ??
>
>
> Indirectly the standards do define APIs at the very least. A good
> example is taskfile. ACPI methods (which we don't yet use) allow get/set
> mode, get features on the motherboard ATA controller if you don't know
> how to drive it. The objects they work in are taskfiles. No taskfiles,
> no ACPI.
Yes, that's true.
Even more is true. Standards and specs define the
_layering infrastructure_ which if implemented,
allows for layer intersection.
For example, if one needs to insert a SATL later just because
the underlaying transport was found able to transport it,
since the layering is well defined and _so_ implemented, it wouldn't
be hard to interface antother well defined layer in.
If, OTOH, things are conglomerated into a blob, just because
the kernel engineers (not (storage) engineers per se) found _no_ current
use of the layering infrastructure and separating the layers
was found do add "more maintenance", then this will turn around
sooner or later to bite back.
After all, things are what they are.
Luben
On 2005-10-03, at 15:54, Luben Tuikov wrote:
> On 09/30/05 19:42, Marcin Dalecki wrote:
>
>> On 2005-10-01, at 00:01, Luben Tuikov wrote:
>>
>>
>>> Why should synchronization between Process A and Process B
>>> reading storage attributes take place in the kernel?
>>>
>>> They can synchronize in user space.
>>>
>>
>>
>> In a mandatory and transparent way? How?
>
> Futex, userspace mutex, etc. All through a user
> space library interface.
They give a means of possible synchronization between beneviolent
users, but not a mandatory lock on the shared resource.
On Mon, 2005-10-03 at 18:29 +0200, Marcin Dalecki wrote:
> On 2005-10-03, at 15:54, Luben Tuikov wrote:
>
> > On 09/30/05 19:42, Marcin Dalecki wrote:
> >
> >> On 2005-10-01, at 00:01, Luben Tuikov wrote:
> >>
> >>
> >>> Why should synchronization between Process A and Process B
> >>> reading storage attributes take place in the kernel?
> >>>
> >>> They can synchronize in user space.
> >>>
> >>
> >>
> >> In a mandatory and transparent way? How?
> >
> > Futex, userspace mutex, etc. All through a user
> > space library interface.
>
> They give a means of possible synchronization between beneviolent
> users, but not a mandatory lock on the shared resource.
>
Nor do they protect against external events, such as disk
insertion/removals, and someone kicking a cable.
On 10/03/05 12:35, Andrew Patterson wrote:
> On Mon, 2005-10-03 at 18:29 +0200, Marcin Dalecki wrote:
>>They give a means of possible synchronization between beneviolent
>>users, but not a mandatory lock on the shared resource.
>>
>
>
> Nor do they protect against external events, such as disk
> insertion/removals, and someone kicking a cable.
As has _always_ been the case in UNIX: Provide capability,
not policy.
The more things are off loaded to userspace the better.
Look at it this way: the deadbolt on your house door does
not _eliminate_ the possibility of someone cleaning out
your house, even if you have a security system and/or
a guard dog.
Same thing here.
Luben
On 2005-10-03, at 18:39, Luben Tuikov wrote:
> On 10/03/05 12:35, Andrew Patterson wrote:
>
>> On Mon, 2005-10-03 at 18:29 +0200, Marcin Dalecki wrote:
>>
>>> They give a means of possible synchronization between beneviolent
>>> users, but not a mandatory lock on the shared resource.
>>
>> Nor do they protect against external events, such as disk
>> insertion/removals, and someone kicking a cable.
>
> As has _always_ been the case in UNIX: Provide capability,
> not policy.
This is at least arguable and not applicable, since we are talking
about Linux and not UNIX here. UNIX is just fine using IOCTL or
SYSCTL instead of a crude pseudo file system for this kind of things.
> The more things are off loaded to userspace the better.
That is not the question at hand and an invalid statement per se.
It's not a design goal in itself to have everything in user space.
However you admitt indirectly that the problem in question is valid
and that it exists on the design level of the interface at hand and
that it's an inherent error in this interface, since you don't know a
solution to it.
> Look at it this way: the deadbolt on your house door does
> not _eliminate_ the possibility of someone cleaning out
> your house, even if you have a security system and/or
> a guard dog.
Problems which can be solved by proper solutions easly and without
cost should be solved and not talked away to justify someones idee
fixe about interface desing.
On Mon, 3 Oct 2005, Luben Tuikov wrote:
> On 10/03/05 12:35, Andrew Patterson wrote:
>> On Mon, 2005-10-03 at 18:29 +0200, Marcin Dalecki wrote:
>>> They give a means of possible synchronization between beneviolent
>>> users, but not a mandatory lock on the shared resource.
>>>
>>
>>
>> Nor do they protect against external events, such as disk
>> insertion/removals, and someone kicking a cable.
>
> As has _always_ been the case in UNIX: Provide capability,
> not policy.
>
> The more things are off loaded to userspace the better.
>
> Look at it this way: the deadbolt on your house door does
> not _eliminate_ the possibility of someone cleaning out
> your house, even if you have a security system and/or
> a guard dog.
But using fs like "presentation" layer have some additional "possibilities"
for race conditions because between open() and flock() some other process
can try open the same file. Also this semantics does not provide locking
tree or subtree of files (do I mention procfs and sysfs do not support
locking ? :)
Next is time/cpu concumption because operate on fs like structures
requires open() -> (flock() ->) read()/write() -> close() .. three or more
context swiching. This is main reason why simple ps takes so many time on
Linux.
Something like simple MIB/OID like semantics for read, write, lock single
OID or subtree could be very good to mandatory locking for operate on
atributes sets and probably will take less memory than sysfs.
<mode=cynic>
But I know this is like fantasy because seems no one want work on
stabilize kernel API. Even more .. Documentation/stable_api_nonsense.txt
included in *stable* line documents real kernel strategy .. it is
*pure folclor* (because from this is possible suck something like: "we are
using specyfication: 'we are hate use specyfications'").
If (cytation from Linus) "a 'spec' is close to useless" ..
Q: why the hell in kernel tree is included Documentation/ subdirectory ?
Is it raly content of this directory is "close to useless" or maybe it not
contains some specyfications ? :>
If it is true maybe better will be remove this ? ;->
Maybe after removing Documentation/ with stable_api_nonsense.txt some
people will can grant permission to start thinking on prepare
specyfication for kernel API usable in longer chunk of time (?)
</mode>
kloczek
--
-----------------------------------------------------------
*Ludzie nie maj? problem?w, tylko sobie sami je stwarzaj?*
-----------------------------------------------------------
Tomasz K?oczko, sys adm @zie.pg.gda.pl|*e-mail: [email protected]*
On Mon, 2005-10-03 at 23:26 +0200, Tomasz K?oczko wrote:
> If (cytation from Linus) "a 'spec' is close to useless" ..
> Q: why the hell in kernel tree is included Documentation/ subdirectory ?
> Is it raly content of this directory is "close to useless" or maybe it not
> contains some specyfications ? :>
Let me rephrase what Linus said, to help remove the misreading that
seems so common today. I think a fair rewording would be, "A spec is a
guideline. When it fails to match reality, continuing to follow it is a
tremendous mistake."
Additionally, I think the overall LKML feeling on hardware specs and the
corresponding software abstractions to deal with it can be summarized
something like this:
When the spec provides a software design that doesn't fit into the
overall structure of the Linux kernel, the spec should be treated as a
suggestion for a software design. The *interface* that the spec
documents should be followed, where it moves out of the overall
structure, but internally, a design that fits into the Linux kernel is
more important than following a spec that doesn't fit.
--
Ryan Anderson
AutoWeb Communications, Inc.
email: [email protected]
On Mon, 3 Oct 2005, Ryan Anderson wrote:
>
> Let me rephrase what Linus said, to help remove the misreading that
> seems so common today. I think a fair rewording would be, "A spec is a
> guideline. When it fails to match reality, continuing to follow it is a
> tremendous mistake."
Yes (and that _should_ be obvious, but seldom is). But even stronger than
that.
Even in the case where a spec follows reality, the organization of the
spec very seldom has anything to do with organization of code.
A lot of people seem to think that spec abstractions should be translated
into code abstraction. Not so. It often makes no sense to do so at all.
There are exceptions. I suspect that pretty much all of them are specs
that _used_ to be code (ie they are documentation of real
implementations).
For example, Al Viro pointed out privately that the C preprocessor spec
actually matches what a C preprocessor is supposed to do, and that it was
easy to generate code from the spec. The reason? The code existed first,
the spec was written from that. Writing it back into software "just
works", because the spec really _was_ software to begin with, just
re-written as a spec.
But when it comes to hardware, almost all specs are written from the
standpoint of the hardware, not the standpoint of the software driving it.
The spec might even tell you accurately what the hardware does (hey,
miracles happen!), but that doesn't mean that you should organize your
software around it.
And the undeniable fact is, that once a spec gets big and complex enough,
it won't be exhaustively tested. For example, we've seen time and time
again that the hardware testing has been totally not based on any spec,
but on just testing against (usually just one, and usually Windows) one
single implementation of the "other side".
So for example, you'll have a general spec that says that the hardware
reacts in certain ways, but the only case that has been _tested_ is the
particular ways that Windows uses. Which is why we have hardware that
locks up when given commands in the wrong order - where "wrong" is not
defined by the spec, but by what Windows just happens to do.
This is especially common in the "cheap" market. For example, for SCSI,
most of the violations tend to be USB storage - which is supposed to act
largely like SCSI, but in reality really doesn't. It locks up if you
try to access sectors that aren't there, etc.
And this is where the spec people come in. They think that the "spec" is
right, and the reality is wrong. So they blame the broken hardware. Which
is "true" to some degree - there's a lot of broken hardware out there. But
it's _pointless_. Broken hardware is not an excuse - it's just a fact of
life. It's not acceptable to say "but the spec says.."
And yes, the real problem with people ignoring reality are often in the
high end. The high end tends to be the place where vendors are used to
saying "we don't use broken hardware". The high end is where people say
"if it doesn't conform to spec, we don't care: it's broken". In short, the
high end is where people are the most likely to just ignore the realities
_outside_ the high end. They'll point to the spec, and say "do it like
this". Without ever caring that doing it like that simply may not _work_
on a lot of setups.
So when the SAS people say that the SCSI layer should conform to their
needs, next time they should remember that it _also_ needs to conform to
the needs of things like USB storage. Which has totally different goals,
implementation issues, and bugs.
Linus
On Mon, Oct 03, 2005 at 03:56:50PM -0700, Linus Torvalds wrote:
> For example, Al Viro pointed out privately that the C preprocessor spec
> actually matches what a C preprocessor is supposed to do, and that it was
> easy to generate code from the spec. The reason? The code existed first,
> the spec was written from that. Writing it back into software "just
> works", because the spec really _was_ software to begin with, just
> re-written as a spec.
Not quite, AFAIK. Existing code was a fscking mess of subtly incompatible
implementations; the thing that had helped was simple - the people who
would have to implement the damn thing had a lot of presense in the
committee. So it boiled down to
* observation: attempt to describe it as text transformation leads
to horrors; it really acts on token stream; give up treating it like a text
filter.
* after figuring out what it should do to sequences of tokens they
ended up with a reasonably simple algorithm that matched the existing
behaviour sans the nasty corner cases everyone handled differently.
* _that_ had been turned into spec.
On Mon, 3 Oct 2005, Ryan Anderson wrote:
> On Mon, 2005-10-03 at 23:26 +0200, Tomasz K?oczko wrote:
> > If (cytation from Linus) "a 'spec' is close to useless" ..
> > Q: why the hell in kernel tree is included Documentation/ subdirectory ?
> > Is it raly content of this directory is "close to useless" or maybe it not
> > contains some specyfications ? :>
>
> Let me rephrase what Linus said, to help remove the misreading that
> seems so common today. I think a fair rewording would be, "A spec is a
> guideline. When it fails to match reality, continuing to follow it is a
> tremendous mistake."
>
> Additionally, I think the overall LKML feeling on hardware specs and the
> corresponding software abstractions to deal with it can be summarized
> something like this:
>
> When the spec provides a software design that doesn't fit into the
> overall structure of the Linux kernel, the spec should be treated as a
> suggestion for a software design. The *interface* that the spec
> documents should be followed, where it moves out of the overall
> structure, but internally, a design that fits into the Linux kernel is
> more important than following a spec that doesn't fit.
Please lets design against the transport or FSM of the storage transport
and never see data again. NCITS specs generally (used loosely) define the
boundary conditions for stable operations. One of jewels of linux in the
past which (hopefully was fixed, was 1.2.X-2.5.X thingy) was buffer_head
walking and release to satisfy transfer of data-blocks of a spindle
against the data-blocks of the kernel. Spindle must win or one can not
insure data integrity, thus the advent of BIO's from BH.
Linux changed to conform to data integrity issues.
Somedays, Linux's API's or designs are OTS (Over The Shoulder).
You get crap all over your back, if you reach OTS to finish your washroom
business. It is functional but ends up stinky and messy.
This thread is getting longer and I just added to piles ...
Sigh
Andre
On Mon, 3 Oct 2005, Luben Tuikov wrote:
> On 10/01/05 19:55, Alan Cox wrote:
> > On Gwe, 2005-09-30 at 19:53 +0200, Arjan van de Ven wrote:
> >
> >>that makes me wonder... why and how does T10 control linux abi's ??
> >
> >
> > Indirectly the standards do define APIs at the very least. A good
> > example is taskfile. ACPI methods (which we don't yet use) allow get/set
> > mode, get features on the motherboard ATA controller if you don't know
> > how to drive it. The objects they work in are taskfiles. No taskfiles,
> > no ACPI.
>
> Yes, that's true.
Luben,
Here was your entry point to state SCSI uses "taskfiles" in the packet
transport.
> Even more is true. Standards and specs define the
> _layering infrastructure_ which if implemented,
> allows for layer intersection.
>
> For example, if one needs to insert a SATL later just because
> the underlaying transport was found able to transport it,
> since the layering is well defined and _so_ implemented, it wouldn't
> be hard to interface antother well defined layer in.
>
> If, OTOH, things are conglomerated into a blob, just because
> the kernel engineers (not (storage) engineers per se) found _no_ current
> use of the layering infrastructure and separating the layers
> was found do add "more maintenance", then this will turn around
> sooner or later to bite back.
Not everyone has to be a "storage engineer", but a "storage engineer" must
be able to explain to any OS developer/engineer the scope of the transport
and work within the OS or explain why a change is required.
A lot of both has happened so ... to quote Elmo:
"ARE WE THERE YETTTTTTTTTTTTTTTTTTTT!"
This process is moving like rush hours in the SF-Bay area.
Cheers,
Andre
On Mon, 3 Oct 2005, Linus Torvalds wrote:
[..]
> This is especially common in the "cheap" market. For example, for SCSI,
> most of the violations tend to be USB storage - which is supposed to act
> largely like SCSI, but in reality really doesn't. It locks up if you
> try to access sectors that aren't there, etc.
Yes .. of course .. but please don't tap some words (without this kind
comment) which sounds like rules [1]. *Especialy if* talk is about *one*
specified piece of hardware. Moving discuss from one point to full
population many people takes as plain trolling. Luben looks like SAS
specialist and if you drive discuss outside SAS area this must be
confusing for him .. and not only for him. And also .. SAS controlers
this is not '"cheap" market'.
[1] look at comments at /. and osnews:
http://linux.slashdot.org/article.pl?sid=05/10/02/218233&tid=8&tid=106
http://osnews.com/comment.php?news_id=12074
look how many people without proper knowledge level assumes: Linus is
authoritet -> Linus says "spec is close to useless" (without looking on
context) -> .. probaly spec is realy useless. Of course it is blind
repeatig but case like this may ruine many thing aroud Linux .. and
forgive me: you must be aware all this.
Thank You, sorry and regards
kloczek
--
-----------------------------------------------------------
*Ludzie nie maj? problem?w, tylko sobie sami je stwarzaj?*
-----------------------------------------------------------
Tomasz K?oczko, sys adm @zie.pg.gda.pl|*e-mail: [email protected]*
On 10/03/05 18:56, Linus Torvalds wrote:
> So when the SAS people say that the SCSI layer should conform to their
> needs, next time they should remember that it _also_ needs to conform to
> the needs of things like USB storage. Which has totally different goals,
> implementation issues, and bugs.
It does, Linus, it does.
SAS/USB/SBP all implement pretty close to SAM architecture
whereby the transport layer (SAS/USB/SBP) sits between
SCSI Core (SAM to be) and the interconnect (USB bus, SAS link,
Infiniband, IEEE1394, TCP/IP, FC, etc).
The reason of all this hoopla is that James B, wants to decree
that LSI/MPT is the norm and everything else (USB/SAS/SBP) is
the exception, while in fact it is the other way around.
This is because 10 years ago, all there was was Parallel SCSI,
and all LLDD implemented Parallel SCSI and above them was SCSI Core.
So in effect there was no need for Parallel SCSI Transport _layer_
between an SPI LLDD and SCSI Core.
What you see in my SAS Code is what you see in USB Storage (sans EH)
and what you see in SBP. It is the same architecture: layered.
Luben
Luben Tuikov wrote:
> The reason of all this hoopla is that James B, wants to decree
> that LSI/MPT is the norm and everything else (USB/SAS/SBP) is
> the exception, while in fact it is the other way around.
False. You continue to misunderstand basic stuff about the SCSI core.
We are trying to support all these crazy configurations... at once :)
Jeff
On 10/04/05 02:51, Andre Hedrick wrote:
>
> Not everyone has to be a "storage engineer", but a "storage engineer" must
> be able to explain to any OS developer/engineer the scope of the transport
> and work within the OS or explain why a change is required.
Can you not have a storage engineer who is also a kernel engineer?
> This process is moving like rush hours in the SF-Bay area.
Standing still,
Luben
On Tue, 4 Oct 2005, Tomasz K?oczko wrote:
>
> On Mon, 3 Oct 2005, Linus Torvalds wrote:
> [..]
> > This is especially common in the "cheap" market. For example, for SCSI,
> > most of the violations tend to be USB storage - which is supposed to act
> > largely like SCSI, but in reality really doesn't. It locks up if you
> > try to access sectors that aren't there, etc.
>
> Yes .. of course .. but please don't tap some words (without this kind
> comment) which sounds like rules [1]. *Especialy if* talk is about *one*
> specified piece of hardware.
What "one" piece of hardware? There's a hell of a lot more broken USB
devices out there (and no, it's not "one" type either) than there will
probably _ever_ be SAS devices.
And the thing is, from a kernel _maintenance_ standpoint, the broken
hardware is the one that is expensive. Maybe only 0.1% of all hardware
ends up having some bugs - but that doesn't matter. It may look like a
"small" percentage to you, but it ends up being a _huge_ burden on
developers to try to figure out what is going on, often _exactly_ because
it's a small percentage, and the developers don't have it.
So the argument that "most hardware conforms to spec" is not a valid
argument. Not if it's 51%, and not if it's 99.9%. Because the cost is in
the ones that don't.
And that is why I'm trying to educate people that specs are purely paper.
Often much less valuable than a roll of TP.
Because what matters is not the spec, but real life. For example, in the
SCSI layer we've ended up being much more successful with the approach of
trying to use the same discovery sequence as Windows - because unlike the
spec, that's REAL LIFE, and that's the case that actually works.
The same way software inevitably has bugs in areas that haven't been
tested, hardware has bugs in areas that haven't been tested. It has
nothing to do with specs, and no, specs don't make people test it.
Linus
On 10/04/05 10:54, Jeff Garzik wrote:
> Luben Tuikov wrote:
>
>>The reason of all this hoopla is that James B, wants to decree
>>that LSI/MPT is the norm and everything else (USB/SAS/SBP) is
>>the exception, while in fact it is the other way around.
>
>
> False. You continue to misunderstand basic stuff about the SCSI core.
Let me repeat: LSI/MPT is not the norm and USB/SAS/SBP, i.e. having
an actual transport layer (handling transport tasks, and error recovery)
is the norm.
Don't make stupid bullshit generalizations that I "continue to
misunderstand basic stuff about the SCSI core".
I've probably misunderstood that LUNs are 32 bit (since SCSI Core
says so) and that REQUEST SENSE clears ACA?
I remember answering your questions on task set aborting several
years ago on linux-scsi.
> We are trying to support all these crazy configurations... at once :)
Oh, I'm well aware of what you're trying to do.
But since the layers are completely upside down one compared
to the other, it would be quite messy unless you can separate
the implementations and at one or the other (but not both)
include a basic emulator. If there is no basic emulator then
that part would have to be taken by the LLDD.
It would be messy.
Luben
Luben Tuikov wrote:
> On 10/04/05 10:54, Jeff Garzik wrote:
>
>>Luben Tuikov wrote:
>>
>>
>>>The reason of all this hoopla is that James B, wants to decree
>>>that LSI/MPT is the norm and everything else (USB/SAS/SBP) is
>>>the exception, while in fact it is the other way around.
>>
>>
>>False. You continue to misunderstand basic stuff about the SCSI core.
>
>
> Let me repeat: LSI/MPT is not the norm and USB/SAS/SBP, i.e. having
> an actual transport layer (handling transport tasks, and error recovery)
> is the norm.
>
> Don't make stupid bullshit generalizations that I "continue to
> misunderstand basic stuff about the SCSI core".
You continue to misunderstand everyone else's opinion. No one is
claiming that LSI/MPT is the norm.
The claim is that the transport class is the method through which a
transport layer is plugged into the SCSI stack. Pluggable transport
classes means that SAS transport layer details go into the SAS transport
class (or a helper lib). SPI (parallel/legacy SCSI) transport layer
details should move to the SPI transport class.
> I've probably misunderstood that LUNs are 32 bit (since SCSI Core
> says so) and that REQUEST SENSE clears ACA?
You misunderstood that everybody, but you, has moved on to the "what do
we do about this" phase.
> But since the layers are completely upside down one compared
> to the other, it would be quite messy unless you can separate
> the implementations and at one or the other (but not both)
> include a basic emulator. If there is no basic emulator then
> that part would have to be taken by the LLDD.
Nothing is upside down. Transport details plug into an obvious location
-- the transport class, and associated helper libs (if any).
Jeff
On 10/04/05 11:26, Jeff Garzik wrote:
> You continue to misunderstand everyone else's opinion.
Internet mailing lists are one such thing where anyone
can write anything they want and sound smart. Like
the statement above.
Did you talk to "everyone else"? Or is this just you,
James B and Christoph?
How do you know everyone else's opinion?
Maybe because you're telling them what they should think?
> The claim is that the transport class is the method through which a
> transport layer is plugged into the SCSI stack. Pluggable transport
No. This isn't currently the case. You're maybe making it now
to be like this, but it is currently not the case.
> classes means that SAS transport layer details go into the SAS transport
> class (or a helper lib). SPI (parallel/legacy SCSI) transport layer
> details should move to the SPI transport class.
"should", "will".
The question is then: Where were you Jeff all this time?
Why did the SAS code had to be posted for SCSI Core to see how many
things it needs to repair.
I've been pointing those things out since, oh well, for many years
now.
> You misunderstood that everybody, but you, has moved on to the "what do
> we do about this" phase.
If SCSI Core had seen the necessary over the years changes,
it wouldn't be in this situation now.
> Nothing is upside down. Transport details plug into an obvious location
> -- the transport class, and associated helper libs (if any).
USB/SAS/SBP:
HW -> LLDD -> Transport Layer -> SCSI Core
MPT:
HW -> Transport Layer (FW) -> LLDD -> SCSI Core.
Luben
On Tue, Oct 04, 2005 at 11:40:17AM -0400, Luben Tuikov wrote:
> On 10/04/05 11:26, Jeff Garzik wrote:
> > You continue to misunderstand everyone else's opinion.
>
> Internet mailing lists are one such thing where anyone
> can write anything they want and sound smart. Like
> the statement above.
>
> Did you talk to "everyone else"? Or is this just you,
> James B and Christoph?
It's mine too, but I hadn't seen the need to perpetuate this stupid
thread.
> "should", "will".
>
> The question is then: Where were you Jeff all this time?
Working on other things? It's not like scsi core is the only armpit
the kernel has.
> Why did the SAS code had to be posted for SCSI Core to see how many
> things it needs to repair.
>
> I've been pointing those things out since, oh well, for many years
> now.
But people have been working on improving scsi core for many years. The
transport classes have a copyright daate of 2003 on them, for example.
> If SCSI Core had seen the necessary over the years changes,
> it wouldn't be in this situation now.
Things take time. Even standards committees.
> > Nothing is upside down. Transport details plug into an obvious location
> > -- the transport class, and associated helper libs (if any).
>
> USB/SAS/SBP:
> HW -> LLDD -> Transport Layer -> SCSI Core
>
> MPT:
> HW -> Transport Layer (FW) -> LLDD -> SCSI Core.
That's why we still need each driver to have a scsi host template. That
way each driver can do what it needs to do. For MPT, that's mostly 'ask
firmware and present the results to sas'. For other SAS drivers, that's
probably 'call this function in the SAS trransport class that does
everything you want'.
If you like, you can think of it as working around a bug. Instead of
doing it in the SAS class, we let the driver fix the layering bug.
