WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: [PATCH] Fix restore handling checks

To: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH] Fix restore handling checks
From: Michal Novotny <minovotn@xxxxxxxxxx>
Date: Wed, 23 Jun 2010 14:12:30 +0200
Cc: Paolo Bonzini <pbonzini@xxxxxxxxxx>, "'xen-devel@xxxxxxxxxxxxxxxxxxx'" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <Keir.Fraser@xxxxxxxxxxxxx>
Delivery-date: Wed, 23 Jun 2010 05:13:20 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <19489.63562.359937.534740@xxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <C8456846.181EC%keir.fraser@xxxxxxxxxxxxx> <4C204D8C.3020303@xxxxxxxxxx> <19488.53018.201328.781032@xxxxxxxxxxxxxxxxxxxxxxxx> <4C21EDA5.5070100@xxxxxxxxxx> <19489.61339.878715.309115@xxxxxxxxxxxxxxxxxxxxxxxx> <4C21F034.7060501@xxxxxxxxxx> <19489.62735.769351.371689@xxxxxxxxxxxxxxxxxxxxxxxx> <4C21F5DC.5050806@xxxxxxxxxx> <19489.63562.359937.534740@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-3.fc13 Thunderbird/3.0.4
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.

Ian.
Right but I don't think someone uses the read-only IDE drives or read-only drives in general - at least for HVM guests since just few days I posted the patch to disallow write to the read-only devices on ioemu - maybe you remember I did post the patch at [1]. Before this patch applied the read-only disks were treated as read-write always no matter what the state of disk device was present in the xenstore so why not to teach the users the right things according to the specs. This shouldn't break anything if you consider you added my patch to xen-ioemu just 13 days ago and I find it rather confusing to let users define read-only IDE disks which is not right according to the specs, this means that by allowing it we could confuse the users so that they can think that read-only IDE disks does exists even according to the specs and they may try to think that the bare-metal IDE disks does support it as well. Since this shouldn't break anything why shouldn't we do the things the right way? They have SCSI disks and PV drivers if they want read-only disks after all.

Michal

[1] http://xenbits.xensource.com/gitweb?p=qemu-xen-unstable.git;a=commit;h=6392763643311272590ef5c6f75ba11d5b132585

--
Michal Novotny<minovotn@xxxxxxxxxx>, RHCE
Virtualization Team (xen userspace), Red Hat


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel