On Jun 28, 2015, at 8:29 PM, Laurent Vivier wrote:
> 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.
The thing is a cdrom would be in the drive, and !bdrv_is_inserted() would
return false.
>
> 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.
I don't think we need a bdrv_host_cdrom registered. If one tiny change could
make the real cdrom drive work, why completely implement this structure?
