qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] block.c: fix real cdrom detection


From: Programmingkid
Subject: Re: [Qemu-devel] [PATCH] block.c: fix real cdrom detection
Date: Thu, 25 Jun 2015 14:07:20 -0400

On Jun 25, 2015, at 12:16 PM, Paolo Bonzini wrote:

> 
> 
> On 25/06/2015 18:12, Laurent Vivier wrote:
>> 
>> 
>> On 25/06/2015 17:48, Paolo Bonzini wrote:
>>> 
>>> On 25/06/2015 17:32, Programmingkid wrote:
>>>>> I think we are going to have to agree to disagree. I have never
>>>>> used the /dev/sr(0 | 1) devices and don't see how they would be
>>>>> effected by this patch. Are you trying to say the /dev/sr(0 | 1)
>>>>> devices *should* be handled by this patch?
>>>> 
>>>> Thinking about your question some more, I see what you mean. On Linux
>>>> /dev/sr0 refers to the cdrom drive. Also on Linux, the /dev/cdrom
>>>> link refers to the /dev/sr0 device file. So if you just use
>>>> /dev/cdrom, you are good.
>>> 
>>> Well, that's not how things work.
>>> 
>>> If you do things like that, you end up with a bunch of hacks, not with a
>>> decent piece of software.
>>> 
>>> There is support for CD-ROM passthrough on Linux and FreeBSD in
>>> block/raw-posix.c.  Perhaps the FreeBSD support can be extended to OS X
>>> as well.
>>> 
>> 
>> In fact, programmingkid, you should fix it in hdev_open() where there is
>> already a #if __APPLE__ .
>> 
>> Paolo, I agree with you but :
>> 
>> hdev_open()
>> 
>> #if defined(__linux__)
>>    {
>>        char resolved_path[ MAXPATHLEN ], *temp;
>> 
>>        temp = realpath(filename, resolved_path);
>>        if (temp && strstart(temp, "/dev/sg", NULL)) {
>>            bs->sg = 1;
>>        }
>> #endif
>> 
>> I'm wondering who had this strange idea... :)
> 
> I was very scared to type "git blame" here. :)  But the question is also
> where to put the checks.  Putting it at a random place in block.c is not
> a good idea.

I honestly think it is in the right place. The function find_image_format()
is doing just that - trying to find the format. The image part of the 
function's name
does bother me. But we could ignore it. Since we know it is a real cdrom drive,
 it would receive the format of raw. It seems as simple as that.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]