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

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

2012/1/17 Ian Campbell <Ian.Campbell@xxxxxxxxxx>:
> On Mon, 2012-01-16 at 17:58 +0000, Ian Jackson wrote:
>> Roger Pau Monnà writes ("Re: [Xen-devel] Driver domains and hotplug scripts, 
>> redux"):
>> > 2012/1/12 Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>:
>> > > Ian Campbell writes ("Re: [Xen-devel] Driver domains and hotplug 
>> > > scripts, redux"):
>> > >> The forceful destroy case is different, it is effectively:
>> > >> 1. rm backend dir in xenstore.
>> > >
>> > > That's (iii). ÂWe want a way to do (ii) as well.
>> >
>> > From my point of view, (iii) should only happen after (i) or (ii) has
>> > failed (timeout or error trying to unplug devices).
>>
>> There has to be a user option to ask for a "very forceful" detach.
>>
>> > What should we do with xend? Are we keeping it on 4.2? I'm asking this
>> > because the changes I'm introducing disables some udev rules that are
>> > needed for xend. The other option is to update xend to talk to
>> > xenbackendd also.
>>
>> I think xend is not going to go away in 4.2, unfortunately.
>
> 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.

I'm not sure this solves our problems, since this doesn't disable udev
exactly, it disables hotplug scripts entirely, but they are needed
from libxl also (my approach uses the current hotplug scripts).

Also, if both xl and xend are running, there are a lot of chances of
getting a mess, since machines started from xl (using the new xenstore
protocol /hotplug/...) could not be stopped successfully from xend,
and the other way around.

> 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.
>
> Ian.
>
> [0] http://lists.xen.org/archives/html/xen-devel/2011-06/msg00952.html

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