public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Marcin Dalecki <dalecki@evision.ag>
To: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>
Cc: martin@dalecki.de,
	Morten Helgesen <morten.helgesen@nextframe.net>,
	linux-kernel@vger.kernel.org
Subject: Re: please DON'T run 2.5.27 with IDE!
Date: Tue, 23 Jul 2002 15:58:58 +0200	[thread overview]
Message-ID: <3D3D6122.5010207@evision.ag> (raw)
In-Reply-To: Pine.SOL.4.30.0207231530450.29134-100000@mion.elka.pw.edu.pl

Bartlomiej Zolnierkiewicz wrote:

> Martin why aren't you telling people all facts?
> It was the default behaviour before your change in IDE 99.
> This patch in practice reverts IDE 99 change.
> 
> You have INTRODUCED a bug and now you try to
> pretend that it wasn't your fault and it was somehow broken before.

Never said that. Sure it was my fault I looked in the wrong direction
I looked at the ide-tcq code, becouse I still dont like the
idea that we pass a pointer for a struct on the local stack down.
(It's preventing the futile hope to make this thingee somehow 
asynchronous form ever taking place.)

I should have looked at SCSI in first place instead indeed.

> Before 2.5.27 code had the same functionality as scsi version.

That's actually not true... At least the setting of the
request rq->flags is significantly different here and there.
However I think but I'm not sure that the fact aht we have rq->special 
!= NULL here has the hidded side effect that we indeed accomplish the
same semantics.

> And yes it will be useful to move it to block layer.

Done. Just needs testing. I have at least an ZIP parport drive, which
allows me to do some basic checks.


BTW.> Having a fill up request queue trashing data transfers
is indicating that there may be are bugs in the generic block layer too. 
If it gets pushed to boundary conditions it's apparently not very 
robust... BTW.> I never ever will understand why
request_fn returns void instead of an status value.
It could save many places where evry single driver
has to call end_request explicitely.



> Regards
> --
> Bartlomiej
> 
> 
>>===== drivers/ide/ide-taskfile.c 1.61 vs edited =====
>>--- 1.61/drivers/ide/ide-taskfile.c	Fri Jul 19 10:18:50 2002
>>+++ edited/drivers/ide/ide-taskfile.c	Tue Jul 23 12:12:55 2002
>>@@ -194,22 +194,16 @@
>>  	request_queue_t *q = &drive->queue;
>>  	struct list_head *queue_head = &q->queue_head;
>>  	DECLARE_COMPLETION(wait);
>>+	struct request req;
>>
>>  #ifdef CONFIG_BLK_DEV_PDC4030
>>  	if (ch->chipset == ide_pdc4030 && buf)
>>  		return -ENOSYS;  /* special drive cmds not supported */
>>  #endif
>>
>>-	rq = __blk_get_request(&drive->queue, READ);
>>-	if (!rq)
>>-		rq = __blk_get_request(&drive->queue, WRITE);
>>-
>>-	/*
>>-	 * FIXME: Make sure there is a free slot on the list!
>>-	 */
>>-
>>-	BUG_ON(!rq);
>>-
>>+	memset(&req, 0, sizeof(req));
>>+	rq = &req;
>>+
>>  	rq->flags = REQ_SPECIAL;
>>  	rq->buffer = buf;
>>  	rq->special = ar;
>>
> 
> 
> 




  reply	other threads:[~2002-07-23 14:01 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-22 19:37 please DON'T run 2.5.27 with IDE! Bartlomiej Zolnierkiewicz
2002-07-22 20:39 ` Andries Brouwer
2002-07-22 23:25   ` Thunder from the hill
2002-07-23  0:39 ` A Guy Called Tyketto
2002-07-23  0:58   ` Thunder from the hill
2002-07-23  1:10     ` Bartlomiej Zolnierkiewicz
2002-07-23  8:03 ` Morten Helgesen
2002-07-23 12:47   ` Bartlomiej Zolnierkiewicz
2002-07-23 13:00     ` Marcin Dalecki
2002-07-23 13:42       ` Bartlomiej Zolnierkiewicz
2002-07-23 13:58         ` Marcin Dalecki [this message]
2002-07-23 19:52           ` Jan Harkes
2002-07-23 20:08             ` Andre Hedrick
2002-07-24 10:24             ` Marcin Dalecki
2002-07-23 20:24           ` Bartlomiej Zolnierkiewicz
2002-07-24 10:30             ` Marcin Dalecki
2002-07-24 10:54               ` Bartlomiej Zolnierkiewicz
2002-07-24 11:35                 ` Marcin Dalecki
2002-07-24 11:53                   ` Jens Axboe
2002-07-24 12:08                     ` Marcin Dalecki
2002-07-24 12:39                   ` Bartlomiej Zolnierkiewicz
2002-07-24 12:41                     ` Jens Axboe
2002-07-24 12:49                       ` Bartlomiej Zolnierkiewicz
2002-07-24 12:50                         ` Jens Axboe
2002-07-24 13:08                           ` Marcin Dalecki
2002-07-24 13:25                             ` Jens Axboe
2002-07-24 13:35                               ` Bartlomiej Zolnierkiewicz
2002-07-24 13:36                                 ` Jens Axboe
2002-07-24 13:38                                   ` Marcin Dalecki
2002-07-24 13:35                               ` Marcin Dalecki
2002-07-24 12:43                   ` Bartlomiej Zolnierkiewicz
2002-07-24 13:10                     ` Marcin Dalecki
2002-07-24 13:21                       ` Bartlomiej Zolnierkiewicz
  -- strict thread matches above, loose matches on Subject: below --
2002-07-22 19:43 Petr Vandrovec
2002-07-22 19:46 ` Bartlomiej Zolnierkiewicz

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=3D3D6122.5010207@evision.ag \
    --to=dalecki@evision.ag \
    --cc=B.Zolnierkiewicz@elka.pw.edu.pl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin@dalecki.de \
    --cc=morten.helgesen@nextframe.net \
    /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