From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MH3Rl-0003gl-7x for qemu-devel@nongnu.org; Wed, 17 Jun 2009 18:17:33 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MH3Rg-0003fW-1I for qemu-devel@nongnu.org; Wed, 17 Jun 2009 18:17:32 -0400 Received: from [199.232.76.173] (port=58011 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MH3Rf-0003fT-SP for qemu-devel@nongnu.org; Wed, 17 Jun 2009 18:17:27 -0400 Received: from mail-qy0-f191.google.com ([209.85.221.191]:34090) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MH3Rf-0000ua-Jl for qemu-devel@nongnu.org; Wed, 17 Jun 2009 18:17:27 -0400 Received: by qyk29 with SMTP id 29so832507qyk.4 for ; Wed, 17 Jun 2009 15:17:27 -0700 (PDT) Message-ID: <4A396B74.3010400@codemonkey.ws> Date: Wed, 17 Jun 2009 17:17:24 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1245270508-23315-1-git-send-email-ehabkost@redhat.com> In-Reply-To: <1245270508-23315-1-git-send-email-ehabkost@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 0/2] Guess host device type from guest device type for block devices List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost Cc: qemu-devel@nongnu.org, Cole Robinson Eduardo Habkost wrote: > This fixes the following issue: > https://bugzilla.redhat.com/show_bug.cgi?id=473154 > > Sometimes a CD-ROM drive path doesn't start with /dev/cdrom, causing problems > if a disk isn't inserted on the drive. With this patch, the floppy and cdrom > drivers are used if using a host block device as backend and the > virtual device type is floppy or CD-ROM. > Filename based probing is bad, but I think your solution is flawed too. It breaks the case where someone does: qemu -hda /dev/volumes/RH5-iso Where /dev/volumes/RH5-iso is just a plain LVM volume. I can think of legitimate reasons to do this. I think a better approach would be to try and issue a cdrom-specific ioctl without side-effects, and then use that probe to decide whether it's a cdrom. For instance, CDROM_DRIVE_STATUS ought to be pretty safe. Long term, I think we want to take a more thorough approach to host devices. First, we should use fstat instead of filenames to determine whether something is a host device. We should then use the info in fstat to determine what type of device it is. Then we can use host-specific mechanisms to determine what the host device type is. For instance, on Linux, the right thing to do is: lstat(path) -> test -e /sys/dev/block/:/capability -> capability & GENHD_FL_CD Regards, Anthony Liguori