From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: Fwd: Re: [PATCH v3 3/5] libxl: call hotplug scripts from libxl for vbd Date: Fri, 11 May 2012 17:26:42 +0100 Message-ID: <1336753602.23818.133.camel@zakaz.uk.xensource.com> References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com> <1334928211-29856-4-git-send-email-roger.pau@citrix.com> <20373.34767.584624.953798@mariner.uk.xensource.com> <4F982F18.2080902@citrix.com> <4F99360E.2010201@citrix.com> <20377.18296.235567.918003@mariner.uk.xensource.com> <1335445762.28015.141.camel@zakaz.uk.xensource.com> <20397.14624.57140.518016@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20397.14624.57140.518016@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: Roger Pau Monne , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On Fri, 2012-05-11 at 17:06 +0100, Ian Jackson wrote: > Ian Campbell writes ("Re: [Xen-devel] Fwd: Re: [PATCH v3 3/5] libxl: call hotplug scripts from libxl for vbd"): > > On Thu, 2012-04-26 at 14:02 +0100, Ian Jackson wrote: > > > I think we need to think about these timeouts. At the very least > > > they're policy which should probably not be hardcoded in libxl; and > > > arguably people might want to be able to specify infinite ("I trust my > > > guest or driver domain and never want to pull the rug out from under > > > its feet") or zero ("this guest or driver domain has gone wrong and I > > > want it killed, now"). > > > > Unless the same is going to be true of the eventual solution (which I > > suppose it may well be?) we should be wary of over engineering the > > interim solution for 4.2. > > I guess. Also xend's poor behaviour in this area (failing hotplug > timeouts) provides something of an excuse... > > > > Perhaps it would be better to do things the other way around, and have > > > an env var for the case where we're _not_ calling the script from > > > udev ? After all, udev config is configuration (at least on my > > > distros) which the user may not update when the software is updated. > > > > It was my suggestion to do it this way so that we don't end up with a > > vestigial env var which must always be set for no real reason after > > we've removed the udev path altogether. > > When we have "removed the udev path altogether" we will still need to > have something to prevent trouble if the udev rules remain for some > reason. > > > I don't really mind though, we could live with that vestigial thing, or > > have another, easier, transition a few releases down the line. > > The vestigial thing can indeed eventually go away. I'm happy for Roger and you to agree whichever sense you think best for the flag. Ian.