Re: I request inclusion of SAS Transport Layer and AIC-94xx into the kernel

[Luben Tuikov <ltuikov@yahoo.com>]

Hi Andre,

--- Andre Hedrick <andre@linux-ide.org> wrote:
> From what I know from history and why I no longer maintain anything,
> (working to get sanity back) is the Maintainer defines direction while
> following a bigger picture.

Yes, and I think you'll agree with me, the Maintainer isn't/shouldn't
necessarily be the person "defining direction".  The reasons are
many but mostly:
  * Documentation/ManagingStyle document (valuable read),
That document _really_ says it _all_.  I suggest all developers, maintainers,
and corporate _management_ reading this thread to read it.

Why should the Maintainer be "defining direction"?  Is this some
religous cult where "Beaver knows best?" (punt intended!)
Or is this a theocratic society here at Linux SCSI? "Pi = 3" ;-)

The maintainership role is and has been _clearly_ defined!  For the
sake of eveyone else, take a look at 2.4 maintainer, 2.6 maintainer,
other subsystem maintainers: defined by example and in word.
So much unlike SCSI Core.

Another also great reason is:
  * Complete, utter and infinite _incompetence_ coupled with too much pride.
It hurts us all.

When it comes down to it SCSI Core is 20 years behind and thus Linux Storage
is 20 years behind.

> Help create a better lie by mapping into the design set forward by James
> and company.  If the goal of Adaptec is to have support then they need to

Yes, this is indeed a very valuable advice.  I hadn't ever looked at it
like that.

What I thought, albeit erroneously, mea culpa, is that Linux actually
_wanted_ to be "the storage OS of choice".  Now I see and realize that
due to neglected management, Linux has very little to do with _storage_.

Linux need to thank the mutitude of storage ignorant customers
willing to pay the buck, because it is _Linux_ (put gasping sound here).

Linux _can_ be the "storage OS of choice", but this will not happen
through neglect, or sheer incompetence coupled with lots of pride.

Back on topic: I'll try to keep up this "Linux storage lie" set forth
by the james-bottomleys of the Linux community.

> buckup and play be to rules at hand.  Remember, most people are open to
> new ideas and better models.  Propose one and you will find backing.

I never have found backing.  It is all in the archives of linux-scsi
mailing list.  What happens is that even if people like your idea
and write to you _privately_ to tell you that they like your
idea, somewhere in their email, they tell you not to cross-post
their message to the list because they have storage products which
need Linux.  The reason for this is that James Bottomley has established
this politics that if you don't agree to his antics, your patches are
never ever going in.  Why else do you think IBM-ers agree with him that
Linux SCSI doesn't need 64 bit LUNS?

_But_ I'm willing to try _again_.  So I'll be proposing something
later this morning.  (You know, all engineers are optimists.)

       Luben

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