From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44219) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZCmdd-0004ll-Cl for qemu-devel@nongnu.org; Wed, 08 Jul 2015 06:31:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZCmdc-0001Wh-8h for qemu-devel@nongnu.org; Wed, 08 Jul 2015 06:31:37 -0400 Date: Wed, 8 Jul 2015 12:31:25 +0200 From: Kevin Wolf Message-ID: <20150708103125.GE4117@noname.redhat.com> References: <55952D97.7040009@redhat.com> <559540F6.9090800@redhat.com> <55954384.9010906@redhat.com> <559544C4.4050809@redhat.com> <55954836.3060700@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55954836.3060700@redhat.com> Subject: Re: [Qemu-devel] [PATCH] raw-posix.c: remove raw device access for cdrom List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laurent Vivier Cc: Peter Maydell , Qemu-block , Stefan Hajnoczi , qemu-devel qemu-devel , Programmingkid , Paolo Bonzini , John Snow Am 02.07.2015 um 16:18 hat Laurent Vivier geschrieben: > > > On 02/07/2015 16:03, Paolo Bonzini wrote: > > > > > > On 02/07/2015 15:58, Laurent Vivier wrote: > >> Since any /dev entry can be treated as a raw disk image, it is worth > >> noting which devices can be accessed when and how. /dev/rdisk nodes are > >> character-special devices, but are "raw" in the BSD sense and force > >> block-aligned I/O. They are closer to the physical disk than the buffer > >> cache. /dev/disk nodes, on the other hand, are buffered block-special > >> devices and are used primarily by the kernel's filesystem code. > > > > So the right thing to do would not be just to set need_alignment, but to > > probe it like we do on Linux for BDRV_O_NO_CACHE. > > > > I'm okay with doing the simple thing, but it needs a comment for non-BSDers. > > So, what we have to do, in our case, for MacOS X cdrom, is something like: > > ... GetBSDPath ... > ... > if (flags & BDRV_O_NOCACHE) { > strcat(bsdPath, "r"); > } > ... I would avoid such magic. What we could do is rejecting /dev/rdisk nodes without BDRV_O_NOCACHE. Kevin