On Jun 26, 2015, at 5:34 AM, Stefan Hajnoczi wrote: > On Thu, Jun 25, 2015 at 11:11:24AM -0400, Programmingkid wrote: >> On Jun 25, 2015, at 9:31 AM, Stefan Hajnoczi wrote: >>> On Tue, Jun 23, 2015 at 02:26:51PM -0400, Programmingkid wrote: >>>> On Jun 23, 2015, at 2:06 PM, John Snow wrote: >>>>> So what's the issue that this patch attempts to fix and how did you >>>>> determine that the fix was needed here? It doesn't look like it respects >>>>> proper abstraction at a glance. >>>> >>>> Without the patch, QEMU would just quit when the "-cdrom /dev/cdrom" >>>> option is given. >>> >>> Why does it quit? >> >> Because of a bug. This is what it prints: "Could not read image for >> determining its format: Invalid argument". > > The bdrv_pread() failure is what need you need to investigate. In the > other sub-thread there have been hints about adding CD-ROM passthrough > support on Mac OS X by filling in the missing parts in > block/raw-posix.c. That should help you get to the bottom of the > problem. > >> This message seems to indicate that QEMU thinks the real cdrom drive is an >> image file. > > If the -drive format= option is not given, QEMU will try to detect the > image format. That's the purpose of the find_image_format() function. > > QEMU does not make a distinction between image files and block devices > because there are valid use cases where a block device uses an image > format. For example, a disk or partition can contain qcow2 data (there > is no partition table or file system, just qcow2).
So what you are saying is if the user enters "-cdrom /dev/cdrom", QEMU is suppose to call find_image_format. If everything goes right, the first if statement should be skipped. Then the bdrv_pread() function should succeed and so should the bdrv_probe_all() function. Is that how it is suppose to work?