From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NDfTy-0007xz-4k
	for qemu-devel@nongnu.org; Thu, 26 Nov 2009 09:38:06 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1NDfTt-0007wg-5Z
	for qemu-devel@nongnu.org; Thu, 26 Nov 2009 09:38:05 -0500
Received: from [199.232.76.173] (port=50870 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NDfTr-0007wO-A4
	for qemu-devel@nongnu.org; Thu, 26 Nov 2009 09:37:59 -0500
Received: from mx1.redhat.com ([209.132.183.28]:6970)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <kraxel@redhat.com>) id 1NDfTq-0000nh-SC
	for qemu-devel@nongnu.org; Thu, 26 Nov 2009 09:37:59 -0500
Message-ID: <4B0E92B1.10903@redhat.com>
Date: Thu, 26 Nov 2009 15:37:37 +0100
From: Gerd Hoffmann <kraxel@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [sneak preview] major scsi overhaul
References: <4AF4ACA5.2090701@redhat.com>	<200911161853.34668.paul@codesourcery.com>	<4B0BCAA1.3090400@redhat.com>	<200911241351.03650.paul@codesourcery.com>
	<4B0D5D36.6080100@redhat.com> <4B0E2EC8.7040309@suse.de>
	<4B0E3B90.5080001@redhat.com> <4B0E5EFD.6060701@suse.de>
	<4B0E60AF.9000508@redhat.com> <4B0E6496.1060203@suse.de>
	<4B0E8EF6.2080106@redhat.com> <4B0E9036.2070400@suse.de>
In-Reply-To: <4B0E9036.2070400@suse.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Hannes Reinecke <hare@suse.de>
Cc: Paul Brook <paul@codesourcery.com>, qemu-devel@nongnu.org

On 11/26/09 15:27, Hannes Reinecke wrote:
> Gerd Hoffmann wrote:
>> sd_done() tries to figure how many sectors it actually got for serious
>> errors.  I don't feel signaling "medium error" for the first sector
>> behind our limit just because we'd like to have smaller requests.

> scsi_end_request is being called with the number of bytes _actually processed_,
> which might be less than the number of bytes requested.
> And the remainder will be retried by the upper layers.

The "number of bytes _actually processed_" must come from somewhere. 
And that somewhere is sd_done() in case of scsi-disks.  See my point now?

cheers,
   Gerd