WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH 2 of 2] libxl: add support for booting PV domains

Roger Pau Monné writes ("Re: [Xen-devel] [PATCH 2 of 2] libxl: add support for 
booting PV domains from NetBSD using raw files as disks"):
> NetBSD still uses the "loop" ("vnd" on NetBSD) device for files,
> because it doesn't have support for qdisk or blktap. If we don't check
> the hotplug-status before removing the vbd from xenstore (and only
> look at state) it might be removed before the hotplug scripts are
> executed, and the disk is never unmounted. This is why we need to
> check the hotplug-status before removing vbd from xenstore. Of course,
> I could call the hotplug scripts from libxl directly (for disk and
> inet interfaces), and we could get rid of xenbackendd.

Right.

Yes, I think you should call the hotplug scripts from libxl and get
rid of xenbackendd.  That is the way we want the Linux world to go,
although of course Linux needs to call hotplug scripts in fewer cases.

> >> @@ -482,7 +519,7 @@ int libxl__devices_destroy(libxl__gc *gc
> >>          tv.tv_usec = 0;
> >>          while (n_watches > 0) {
> >>              if (wait_for_dev_destroy(gc, &tv)) {
> >> -                break;
> >> +                continue;
> >>              } else {
> >>                  n_watches--;
> >>              }
> >
> > I'm not sure I understand this change, or why it's needed.
> 
> This change is more explained in the series, basically libxl was not
> waiting for all devices to disconnect, because when it returned from
> wait_for_dev_destroy exited the loop immediately, even if we where
> watching for more than one device to disconnect.

Right.

Ian.

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