qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Re: KVM call agenda for July 27


From: Markus Armbruster
Subject: Re: [Qemu-devel] Re: KVM call agenda for July 27
Date: Wed, 28 Jul 2010 13:22:49 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

Anthony Liguori <address@hidden> writes:

> On 07/27/2010 10:22 AM, Markus Armbruster wrote:
>> Kevin Wolf<address@hidden>  writes:
>>
>>    
>>> Am 27.07.2010 15:00, schrieb Anthony Liguori:
>>>      
>>>> On 07/27/2010 02:19 AM, Markus Armbruster wrote:
>>>>        
>>>>> Anthony Liguori<address@hidden>   writes:
>>>>>
>>>>>
>>>>>          
>>>>>> - any additional input on probed_raw?
>>>>>>
>>>>>>            
>>>>> Isn't it a fait accompli?  I stopped providing input when commit
>>>>> 79368c81 appeared.
>>>>>
>>>>>          
>>>> No.  79368c81 was to close the security hole (and I do consider it a
>>>> security hole).  But as I mentioned on the list, I'm also not satisfied
>>>> with it and that's why I proposed probed_raw.  I was hoping to get a
>>>> little more input from those that objected to 79368c81 as to whether
>>>> probed_raw was more agreeable.
>>>>        
>>> Actually I believe qraw is less agreeable. It just too much magic. You
>>> wouldn't expect that your raw images are turned into some other format
>>> that you can't mount or use with any other program any more.
>>>      
>> I also dislike probed_raw, for the same reasons.
>>
>> Raw can't be probed safely, by its very nature.  For historical reasons,
>> we try anyway.  I think we should stop doing that, even though that
>> breaks existing use relying on the misfeature.  Announce it now, spit
>> out scary warnings, kill it for good 1-2 releases later.
>>
>> If we're unwilling to do that, then I'd *strongly* prefer doing nothing
>> over silently messing with the raw writes to sector 0 (so does
>> Christoph, and he explained why).
>
> If we add docs/deprecated-features.txt, schedule removal for at least
> 1 year in the future, and put a warning in the code that prints
> whenever raw is probed, I think I could warm up to this.
>
> Since libvirt should be insulating users from this today, I think the
> fall out might not be terrible.

Okay, I'll prepare a patch.



reply via email to

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