From: Jens Axboe <axboe@suse.de>
To: Andre Hedrick <andre@linux-ide.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
Daniel Stodden <stodden@in.tum.de>,
linux-kernel@vger.kernel.org,
Linus Torvalds <torvalds@transmeta.com>
Subject: Re: hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Date: Fri, 28 Dec 2001 11:59:56 +0100 [thread overview]
Message-ID: <20011228115956.E2973@suse.de> (raw)
In-Reply-To: <20011227155403.A1730@suse.de> <Pine.LNX.4.10.10112271046070.24491-100000@master.linux-ide.org>
In-Reply-To: <Pine.LNX.4.10.10112271046070.24491-100000@master.linux-ide.org>
On Thu, Dec 27 2001, Andre Hedrick wrote:
>
> I would provide patches if you had not goat screwed the block layer and
> had taken a little more thought in design, but GAWD forbid we have design.
You still have zero, absolutely zero facts. _What_ is screwed?
> You have made it clear that you do not believe in testing the data
> transport layers in storage.
That's not true. I would not mind such a framework. What I opposed was
you claiming that you can _proof_ data correctness. Verifying data
integrity and proof are two different things.
> Translation: You do not care if data gets to disk correctly or not.
Bullshit.
> You have stated you do not believe in standards, thus you believe less in
> me because I "Co-Author" one for NCITS.
Please stop misquoting me. _You_ claim that if you have the states down
100% from the specs, then your driver is proofen correct. I say that
believing that is an illusion, only in a perfect world with perfect
hardware would that be the case.
> You have stated the tools of the trade are worthless but you have an ATA
> and SCSI analyzer but you refuse to use them. I know you have them
> because I know who provided them to you.
Again, I've _never_ made such claims. I have the tools, yes, and they
are handy at times.
> Maybe when you get off your high horse and begin to listen, I will quit
> being the ASS pointing out your faulty implimentation of BIO. Maybe when
> you decide it is important we can try to work togather again.
... obviously no need for me to comment on this.
> One thing you need to remember, BLOCK is everybodies "BITCH".
> FileSystems dictate to BLOCK there requirements.
> Low_Level Drivers dictate to BLOCK there rulesets.
> BLOCK is there to bend over backwards to make the transition work.
> BLOCK is not a RULE-SETTER, it is nothing but a SLAVE, and it has to be
> damn clever. One of you assests is you are "clever", but that will not
> cover your knowledge defecits in pure storage transport.
I agree.
> Now I am tired of this game you are playing, so lets spell it out.
>
> Congratulations of your copying of the rq->special for the CDB transport
> out of the ACB driver that myself and two other people authored.
Strictly a cleanup, what's your point?
> Congratulations on you first attempts to create the "pre-builder" model
> that myself and one other has described to you, to bad you did not listen
> 9 months ago or you would have the bigger picture.
I did it now because it's easy to do, comprende? It can be done cleanly
because elv_next_request is there now.
> BUZZIT on mixing two issues that are volitale on there own rights to sort
> out. The high memory bounce and block are two different changes, and one
> is dependent on the other, regardless if you see it or not.
Explain.
> BUZZIT on your short sightedness on the immediate intercept of command
> mode
Explain
> BUZZIT on you himem operations that is not able to perform the vaddr
> windowing for the entire request, but choose to suffer the latency of
> single sector transaction repetion.
s/single sector/single segment. And that temp mapping is done for _PIO_
for christ sakes, I challenge you to show me that being a bottleneck in
any way at all. Red herring.
> BUZZIT on your total lack of documention the the changes to the
> request_struct, otherwise I could follow your mindset and it would not be
> a pissing contest.
Tried reading the source?
> BUZZIT on your moving CDROM operations to create a bogus BLOCK_IOCTL, for
> what? Who know it may have some valid usage, but CDROM is not it.
That part isn't even started yet, block_ioctl is just to show that
rq->cmd[] and ide-cd does work with passing packet commands around.
> BUZZIT on your cut and past in block to make an effective rabbit warren or
> chaotic maze to make it total opaque in what is really going on.
Again, what are you talking about?
Congratulations on spending so much time writing an email with very
little factual content. Here's an idea -- try backing up your statements
and claims with something besides hot air.
--
Jens Axboe
next prev parent reply other threads:[~2001-12-28 11:01 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-06 6:13 hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error } Daniel Stodden
2001-12-06 6:55 ` Sven.Riedel
2001-12-06 15:04 ` Matthias Andree
2001-12-23 7:24 ` Andre Hedrick
2001-12-23 7:53 ` Andrew Morton
2001-12-22 20:25 ` T. A.
2001-12-23 11:18 ` Peter Osterlund
2001-12-23 13:31 ` Alan Cox
2001-12-23 22:08 ` Andre Hedrick
2001-12-27 14:54 ` Jens Axboe
2001-12-27 16:42 ` Alan Cox
2001-12-27 16:51 ` Jens Axboe
2001-12-27 17:46 ` Linus Torvalds
2001-12-27 18:32 ` Andre Hedrick
2001-12-27 21:15 ` Legacy Fishtank
2001-12-27 17:50 ` Alan Cox
2001-12-28 2:05 ` Andre Hedrick
2001-12-28 10:59 ` Jens Axboe [this message]
2001-12-28 12:29 ` Rik van Riel
2001-12-28 12:33 ` Jens Axboe
2001-12-28 13:00 ` Jens Axboe
2001-12-28 19:30 ` Peter Osterlund
2001-12-29 15:07 ` Jens Axboe
2001-12-28 20:23 ` Andre Hedrick
2001-12-29 14:15 ` Jens Axboe
2001-12-29 20:58 ` You WIN Andre Hedrick
2001-12-31 12:58 ` Jens Axboe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20011228115956.E2973@suse.de \
--to=axboe@suse.de \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=andre@linux-ide.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stodden@in.tum.de \
--cc=torvalds@transmeta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox