Re: [Xen-devel] Driver domains and hotplug scripts, redux

[Roger Pau Monnà <roger.pau@xxxxxxxxxxxxx>]

2012/1/17 Ian Campbell <Ian.Campbell@xxxxxxxxxx>:
> On Tue, 2012-01-17 at 10:00 +0000, Roger Pau Monnà wrote:
>> 2012/1/17 Ian Campbell <Ian.Campbell@xxxxxxxxxx>:
>> > On Tue, 2012-01-17 at 09:40 +0000, Roger Pau Monnà wrote:
>> >> 2012/1/17 Ian Campbell <Ian.Campbell@xxxxxxxxxx>:
>> >> > However xend should not be transition to this new scheme but should
>> >> > continue to use its existing scripts in the current manner.
>> >> >
>> >> > There was a conversation last year[0] about how a toolstack could
>> >> > opt-in/out of the use of the hotplug scripts. We decided that toolstacks
>> >> > should have to opt into the use of these scripts, by touching a stamp
>> >> > file.
>> >> >
>> >> > Although this wasn't implemented yet (unless I missed it) I guess the
>> >> > same scheme would apply to this work if that sort of thing turns out to
>> >> > be necessary.
>> >>
>> >> Sorry for replying so many times, this is a big maybe, and possibly
>> >> it's too drastic, but after this changes xl and xend will not be
>> >> compatible anymore, so why don't we disable xend by default, and only
>> >> build xl?
>> >
>> > I don't think they are compatible now, are they? I've certainly seen odd
>> > behaviour when using xl with xend (accidentally) running, usually xend
>> > reaps the domain I've just started...
>> >
>> > I'm all for disabling the build of xend by default but I had assumed
>> > that others would think 4.2 was rather an aggressive timeline for that.
>> >
>> >> When the new configure script is in, it will be trivial to select if
>> >> you want xl or xend, and only install one of those. Adding the option
>> >> --enable-xend should disable xl and only build and install xend
>> >> (printing a very big warning that xend is deprecated).
>> >
>> > I don't think --enable-xend should ever disable xl (or vice versa). Many
>> > folks (e.g. distros) will want to build both, perhaps to package them in
>> > two different binary packages, but certainly to offer their users the
>> > choice, at least for the time being.
>>
>> My main concern with this is that xend and xl will start to use
>> different udev rules (well, xend will continue to use the existing
>> ones, while xl will only use a subset of those). So we have to decide
>> which udev rules file to install, because we can't have both installed
>> at the same time.
>
> Sure we can. Perhaps they need to have an "if $TOOLSTACK" check (e.g. if
> [ -f /var/run/xend.hotplug ]) added to the top, that is all.
>
>> Another option is to install xl udev rules by default, and make xend
>> move it's own rules in the init script.
>
> I don't think initscripts should be messing with udev rules.
>
> Perhaps the opt-in needs to be more fine grained e.g. opt-in to vif but
> not block scripts or whatever distinction you think is necessary instead
> of jut a global opt in, it's just a different naming convention for the
> stamp file. This avoids reconfiguration and the need to install subsets
> of the scripts etc.
>
>> ÂSince xl doesn't use a daemon,
>> xl should always check if xend is running before doing anything and
>> fail if xend is found.
>
> I think that is a separate question/issue to the one of hotplug scripts.

I've posted a WIP the other week about calling hotplug scritps from
libxl, by the end of this week or the beginning of the following I
will try to post the finished driver domain series, and then we can
decide how to fix xend to preserve compatibility.

With all this, is there a deadline for 4.2? I will really like to have
driver domains added to 4.2.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel