From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michal Novotny Subject: Re: Re: [PATCH] Fix restore handling checks Date: Wed, 23 Jun 2010 14:20:27 +0200 Message-ID: <4C21FC0B.5020604@redhat.com> References: <4C204D8C.3020303@redhat.com> <19488.53018.201328.781032@mariner.uk.xensource.com> <4C21EDA5.5070100@redhat.com> <19489.61339.878715.309115@mariner.uk.xensource.com> <4C21F034.7060501@redhat.com> <19489.62735.769351.371689@mariner.uk.xensource.com> <4C21F5DC.5050806@redhat.com> <19489.63562.359937.534740@mariner.uk.xensource.com> <4C21F99E.7070807@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4C21F99E.7070807@redhat.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Paolo Bonzini Cc: "'xen-devel@lists.xensource.com'" , Ian Jackson , Keir Fraser List-Id: xen-devel@lists.xenproject.org On 06/23/2010 02:10 PM, Paolo Bonzini wrote: > On 06/23/2010 02:04 PM, Ian Jackson wrote: >> Michal Novotny writes ("Re: [PATCH] Fix restore handling checks"): >>> Are you saying that it's OK for administrators to violate the IDE specs >>> and do it the way that is should never be done since this way it's not >>> working on bare-metal systems ? This is the breach and it shouldn't be >>> done this way so why to allow it? Shouldn't we care the code complies >>> with the specifications to have it done the right way? >> >> The job of the programmer is to give effect to the wishes of the >> users, not to comply with rules from elsewhere. If the wishes of the >> users conflict with rules from elsewhere, including specs, then the >> programmer should do what the user wants. > > Telling him that he wanted something that cannot be _emulated_ > accurately is also a possibility. But we can agree to disagree here > and Michal can remove this part of the patch. > > Paolo > Well, just one correction to this Paolo. It can be emulated but the emulation doesn't comply to the specifications and since it was never supported at least for HVM guests prior to my patch to fix read-only image handling so it shouldn't break anything so if it was not emulated before the patch I sent 13 days ago why not to emulate/implement it the right way? I don't see any reason to emulate it the wrong way since we know the right way that's been implemented/fixed just 13 days ago - at least for HVM guests. If users want to use read-only drives they can use SCSI drives so what's the problem here? Surely, I can remove this part of the patch but I'm just trying to tell the readers of this thread that I don't see much point in having the wrong implementation. I don't think users want to do it the wrong way and I think they could understand that this is not supported and that they should use SCSI drive definition for read-only drives instead. -- Michal Novotny, RHCE Virtualization Team (xen userspace), Red Hat