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: Thu, 14 Mar 2013 18:03:05 +0100 Message-ID: <514202C9.5060905@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> <5140A3A8.7040400@citrix.com> <20800.42204.657361.448395@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.42204.657361.448395@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 17:10, Ian Jackson wrote: > Roger Pau Monne writes ("Re: [Xen-devel] [PATCH v1 05/12] libxl: add new hotplug interface support to hotplug script callers"): >> On 13/03/13 15:53, Ian Jackson wrote: >>> 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. > > Surely this should be in the same patch ? In general the document for > something should be in the same patch as the code that introduces it. > > TBH I'm not sure I understand the division between the various > patches. I've just added it as a separate patch because I wanted to add it once the implementation in libxl was complete, but I don't have any problem squashing the doc into this patch. Regarding the order of the series, I've basically added the core functionality first in this patch, and then I went adding the missing bits all over the other patches, trying to keep them small and concrete. > >>> 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. > > Yes, of course. Sorry, I was unclear. I meant that there were > aspects about the old calling convention which you are inheriting into > the new one which may want to be revisited. I'm not sure I follow you here, there's a switch in libxl__hotplug_disk that passes completely different parameters and env vars depending on the hotplug script version, so there's no inheritance between the old and the new calling convention.