From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= Subject: Re: [PATCH RFC 02/10] libxl: add new hotplug interface support to hotplug script callers Date: Mon, 21 Jan 2013 13:11:49 +0100 Message-ID: <50FD3085.5030102@citrix.com> References: <1356109208-6830-1-git-send-email-roger.pau@citrix.com> <1356109208-6830-3-git-send-email-roger.pau@citrix.com> <1358515771.3279.33.camel@zakaz.uk.xensource.com> <50F9773E.5060406@citrix.com> <1358762852.3279.161.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1358762852.3279.161.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 21/01/13 11:07, Ian Campbell wrote: > On Fri, 2013-01-18 at 16:24 +0000, Roger Pau Monne wrote: >> On 18/01/13 14:29, Ian Campbell wrote: >>> On Fri, 2012-12-21 at 17:00 +0000, Roger Pau Monne wrote: >>>> Add support to call hotplug scripts that use the new hotplug interface >>>> to the low-level functions in charge of calling hotplug scripts. This >>>> new calling convention will be used when the hotplug_version aodev >>>> field is 1. >>> >>> Is there perhaps some way we can avoid users having to think about the >>> hotplug_version? >>> >>> For example if we export XENBUGS_PATH as a synonym for BACKEND_PATH and >>> arrange that the new protocol involves calling action "add" and >>> "remove" (as well as the other new ones) do old scripts mostly Just Work >>> because they ignore the prepare/unprepare calls? (as a small sample >>> vif-bridge and block-nbd seem to). >> >> I'm afraid old scripts will return an error when called with commands >> different than "add" or "remove", this is from block-common.sh: >> >> if [ "$command" != "add" ] && >> [ "$command" != "remove" ] >> then >> log err "Invalid command: $command" >> exit 1 >> fi > > That's a shame. > >>> Alternatively by way of backwards compat perhaps we could provide a >>> wrapper script? So if today you use script="/my-custom-script" you would >>> switch to script="/etc/xen/hotplug-compat-wrapper /my-custom-script" and >>> the wrapper would shim or ignore the new calls into the old? >> >> Well, from a user point of view, this will still be the same, old >> hotplug scripts will be called using the "script" config option, so >> there will be no need to change configuration files. The only difference >> is that when calling hotplug scripts using the new hotplug interface >> users should use "method" instead of "script" in their config file, as >> an example this would be the diskspec line to attach a disk using the >> iSCSI block script: >> >> 'method=block-iscsi,vdev=xvda,target=iqn=iqn.1994-04.org.netbsd.iscsi-target:target0,portal=192.168.1.128' >> >> Users don't have to deal directly with hotplug_version, I think forcing >> them to user a wrapper is worse, because that will mean modifications to >> config files when updating. > > But "users" of libxl do need to care about hotplug_version? Yes libxl users need to care about hotplug_version, I misunderstood you and thought you were talking about xl users, not libxl users. > > I'm not sure what the answer is here but it would be good if everyone > writing a toolstack using libxl didn't have to think about what kind of > script each one was calling. > > Could we perhaps mandate the new scripts have a certain comment or other > grepable property or that they must react without error to a particular > probing command line option "--are-you-a-v2-script" and have libxl probe > using that? If we choose to use think approach we can also get rid of "method", since libxl will be able to auto-detect script type and react accordingly. I don't have any preference regarding the way to do this auto-detection, but maybe stating that the script should return 0 (success) when called with the action "support_v2" could be a good way. I prefer this rather that having a comment somewhere, since hotplug scripts can be in any kind of programming language (or even in binary form AFAIK), this could become more complicated that it seems now.