From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= Subject: Re: [PATCH v1 05/12] libxl: add new hotplug interface support to hotplug script callers Date: Wed, 13 Mar 2013 17:04:56 +0100 Message-ID: <5140A3A8.7040400@citrix.com> References: <1358963317-10221-1-git-send-email-roger.pau@citrix.com> <1358963317-10221-6-git-send-email-roger.pau@citrix.com> <20800.37611.213635.307260@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20800.37611.213635.307260@mariner.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 Jackson Cc: Ian Campbell , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 13/03/13 15:53, Ian Jackson wrote: > Roger Pau Monne writes ("[Xen-devel] [PATCH v1 05/12] libxl: add new hotplug interface support to hotplug script callers"): >> Add support to call hotplug scripts that use the new hotplug interface >> to the low-level functions in charge of calling hotplug scripts. >> >> libxl__prepare_ao_device sets the hotplug version to 1, in later >> patches hotplug version will be set to 2 by the caller to use this >> new hotplug calling convention. > > I think this needs a comprehensive document describing the new calling > convention. Since there isn't currently a document describing the old > calling convention I think you may need to do some reverse > engineering. Patch 11/12 adds a document describing the new calling convention. > > And then when you do that, there are things about the old calling > convention which are distinctly dodgy and should perhaps be changed. I would prefer to avoid touching anything related to the old calling convention, mainly because I would like to avoid touching the old hotplug scripts in this series, and because there might be out-of-tree hotplug scripts relaying on some of this obscure features. > Is this autoprobing with the "version" argument really the best way to > deal with compatibility ? I guess we do know that it's reliable. I think it's quite reliable, unless someone has an out-of-tree v1 hotplug script that implements this parameter, but I don't think this is going to be the case.