Hi, On 29/06/2015 01:43, Programmingkid wrote: > > On Jun 25, 2015, at 2:01 PM, Peter Maydell wrote: > >> On 25 June 2015 at 18:56, Programmingkid >> <programmingk...@gmail.com> wrote: >>> Nice to hear from you again Laurent. The only way a solution in >>> hdev_open() would work is if it could prevent >>> find_image_format() from executing. Otherwise find_image_format() >>> would just quit QEMU with an error. >> >> The question you should be asking is "what is Linux doing for raw >> CDROM devices that is different, such that it works there but >> doesn't work on OSX?". >> >> It would also be helpful to know which is the case that doesn't >> work. Does QEMU fail in all cases, or only if the cdrom drive is >> empty, or only if there's a disk in the drive? > > QEMU fails if the cdrom is specified "-cdrom /dev/cdrom", and there > is no cd in the drive. > > QEMU also fails with a real cdrom in the drive. > >> >> My initial suspicion is that we need OSX support in raw-posix.c for >> handling the host CDROM specially -- note that Linux and FreeBSD >> register a bdrv_host_cdrom with an is_inserted function. > > The is_inserted function wouldn't make a difference.
In fact, if your patch fixes the problem, the is_inserted with no cdrom should too: with your " strcmp("/dev/cdrom", filename) == 0 ", you force the selection of bdrv_raw (which is what to do). without your patch, if "bdrv_is_inserted()" was implemented and no cdrom in the drive " !bdrv_is_inserted(bs) " should also select bdrv_raw. It appears also that bdrv_host_cdrom is not registered in bdrv_file_init(). I think this is the missing part to have a host cdrom support on MacOS X. Laurent