Date: Sun, 14 Jul 2002 14:23:39 -0700 (PDT)
From: Andre Hedrick <andre@linux-ide.org>
To: Joerg Schilling <schilling@fokus.gmd.de>
cc: linux-kernel@vger.kernel.org
Subject: Re: IDE/ATAPI in 2.5
In-Reply-To: <200207141347.g6EDlU9k019093@burner.fokus.gmd.de>
Message-ID: <Pine.LNX.4.10.10207141401550.31243-100000@master.linux-ide.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3336
Lines: 77

On Sun, 14 Jul 2002, Joerg Schilling wrote:

> >Now your silly PCATA stupid ass Tailgate Bridge that you are boasting
> >about does some of the worst things anyone could ever imagine.
> 
> ???? Looks stupid (like dou did not get the message).

I guess I need to break it down to simple terms, and hoped that your
broadcast in expertise could cover your mouth.  This makes it harder for
me because I do not communicate well over email.

Firewire 1394, USB, Parallel Port, PCMCIA/CardBus are all effective
tailgates via an alternate physical transport layer and protocol.
Therefore it should be obvious many different versions of the hardware get
it wrong.  Now in other operating system which are commerial based, there
are device specific drivers to perform soft-protocol corrections to
generate the appearance of a perfect product.  Much as in optics, here is
another case where two wrongs make a right.  COSTAR for Hubble Space
Telescope is real world example.

> >BurnProof is a result lame devices which improperly hold off the bus
> >because release the BUSY Bit while still performing transfers.
> >The very fact that a huge pile of devices went into the market place
> >based on SFF-8020 rev 2.5 total roasts your strawman, please try again.
> 
> Again: this is completely unrelated to the problem. Why do you introduce
> it?

This to counter your grand statement of there are no problems with any
ATAPI devices after 1993.  Yet anyone who know about the physical bus
layer to support the ATAPI protocol, would realize problems generated by
that document.  Now moving forward in time, there is a conflict in
operations between SFF-8020 rev 2.6 and Mt. Fuji and MMC and lastly Mt.
Rainer.

If you knew anything about the production industry, and maybe you do, it
would be obvious that most of the Far East and Pacific Ring hardware
people are still creating product based on SFF-8020 a retired document.

Yet you stand here and glorify straight SCSI as the transport with a
wrapper assuming that Mt. Fuji and MMC 1/2/3 out of T10 and STA will solve
all the problems of the world.

Your world thinks all hardware regardless is perfect, and that is nice.
My world knows different and attempts to let you continue to enjoy the
fantasy.

> >So instead of whining about what is there and not from your location in
> >end user land, try and offer something useful like a preferred API to
> >allow clean packet-driver interfaces.  Doing that little would allow the
> >transport layer people and the transistion-api folks to user land to
> >greatly increase compatablity.  Then you would not need 5 interfaces for
> >Linux.
> 
> >Have a good day.
> 
> I am not whining, but you answer with  unrelated stuff. Why? Are you missing
> experience and arguments?

I just asked you for a formal preferred model coresponding to READ/WRITE
10/16 fixed to the OS standard CDB as the base of a Packet Interface, yet
you counter with a redirect. :-/

Put up or shut up.

Insert "Joerg Schilling" Perfect Packet Interface for review.

Thank you for the chortle,

Andre Hedrick
LAD Storage Consulting Group

-
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/