From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K0AiF-0008DR-Kg for qemu-devel@nongnu.org; Sun, 25 May 2008 03:32:15 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K0AiD-0008DF-Eq for qemu-devel@nongnu.org; Sun, 25 May 2008 03:32:14 -0400 Received: from [199.232.76.173] (port=47477 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K0AiD-0008DC-9F for qemu-devel@nongnu.org; Sun, 25 May 2008 03:32:13 -0400 Received: from mx20.gnu.org ([199.232.41.8]:14348) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1K0AiD-0003t0-3c for qemu-devel@nongnu.org; Sun, 25 May 2008 03:32:13 -0400 Received: from tapir.sajinet.com.pe ([66.139.79.212]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1K0AiB-0001WP-7w for qemu-devel@nongnu.org; Sun, 25 May 2008 03:32:11 -0400 Date: Sun, 25 May 2008 02:53:19 -0500 From: Carlo Marcelo Arenas Belon Subject: Re: [Qemu-devel] [PATCH] Fix ATAPI GET_CONFIGURATION function Message-ID: <20080525075319.GA2627@tapir> References: <48343300.7050902@suse.de> <51775D7B-EA5B-471C-A664-ADA734850CB6@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51775D7B-EA5B-471C-A664-ADA734850CB6@suse.de> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: paul@codesourcery.com On Sat, May 24, 2008 at 12:31:01PM +0200, Alexander Graf wrote: > Is there anything particularly wrong with this patch? no, but the SPEC (I used MMC6 r01) says : 6.5.1.4 Allocation Length The Allocation Length field specifies the maximum length in bytes of the Get Configuration response data. An Allocation Length field of zero indicates that no data shall be transferred. This condition shall not be considered an error. this is only implicitly supported by truncating the response using max_len for the ide_atapi_cmd_reply with your patch and so the work of generating the response is still happening regardless. > Does it break any guest OSs I am not aware of? the original implementation (*) broke [Open]Solaris by overflowing the buffer that was used in the calls to detect the CDROM/DVDROM (using a 8 byte buffer) Carlo (*) http://svn.savannah.gnu.org/viewvc/trunk/hw/ide.c?root=qemu&r1=3147&r2=3161