From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42643) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YXlqw-0004Lr-KH for qemu-devel@nongnu.org; Tue, 17 Mar 2015 03:23:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YXlqt-0005NK-Ce for qemu-devel@nongnu.org; Tue, 17 Mar 2015 03:23:50 -0400 Message-ID: <5507D680.5030507@suse.de> Date: Tue, 17 Mar 2015 08:23:44 +0100 From: Alexander Graf MIME-Version: 1.0 References: <1425939893-14404-1-git-send-email-mark.cave-ayland@ilande.co.uk> In-Reply-To: <1425939893-14404-1-git-send-email-mark.cave-ayland@ilande.co.uk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC 0/2] macio: split out unaligned DMA access into separate functions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mark Cave-Ayland , qemu-devel@nongnu.org, qemu-ppc@nongnu.org, kwolf@redhat.com, stefanha@redhat.com On 09.03.15 23:24, Mark Cave-Ayland wrote: > This patchset attempts to separate out the IDE/ATAPI logic from the unaligned > DMA access logic for macio which provides the following benefits: > > 1) Reduced code complexity > > The existing macio IDE/ATAPI functions were becoming extremely difficult to > follow through the various callbacks. By splitting up the functions in this > way it becomes much easier to follow the DMA-specific sections of code. > > 2) Future-proofing > > If/when the block layer becomes able to handle unaligned DMA accesses directly > then it should be possible to switch out pmac_dma_read() and pmac_dma_write() > with their unaligned-capable bdrv_*() equivalents without having to change any > other logic. > > 3) Fix intermittent CDROM detection under -M g3beige > > The code refactoring now correctly handles non-block ATAPI transfers which > fixes the problem with intermittent CDROM detection with Darwin under > -M g3beige. > > Signed-off-by: Mark Cave-Ayland Works for me, I'd still prefer to just see unaligned bdrv_*() functions and remove most of the logic we have here. Either way, I think this is a reasonable intermediate step. Alex