Re: [Xen-devel] Fwd: Re: [PATCH v3 3/5] libxl: call hotplug scripts from libxl for vbd

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel