[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 3/5] libxl: add support for vscsi



(Note that I'm not very familiar with this, so what I'm talking might be
non-sense, and please bear with me if I ask stupid questions.)

On Wed, Jan 27, 2016 at 11:00:12AM +0100, Olaf Hering wrote:
> On Fri, Nov 13, Olaf Hering wrote:
> 
> > Port pvscsi support from xend to libxl:
> 
> How should code which converts devices from xenstore to json handle
> devices which got marked as "to be removed"?
> 
> In my pvscsi code I set XenbusStateClosing in the vscsidev, then
> XenbusStateReconfiguring in vscsictrl. This causes the backend/frontend
> to reevaluate the vscsi bus. During that timeframe some other code can
> walk xenstore and find such a device. In libxl__vscsi_fill_host below
> such device gets the ->remove flag. This flag is handled elsewhere to
> indicate that its not an active device anymore. IanC asked to remove the
> flag and I'm converting the code to work without such flag. The question
> still stands what to do with such devices when filling the list of
> vscsidevs on a vscsictrl. Is it up to the caller to inspect the state of
> each vscsidev to decide what to do with it? Or should the function below
> just skip the device right away?
> 
> I think in the current state the device would endup in d_config and in json.
> 

If it is to be removed, why don't you just filter it out and not have it
in JSON at all? This is provided libxl won't rely on that to do proper
clean-up I don't see the value of retaining them, and if libxl is
relying on the JSON file to do clean-up the design is probably wrong.

In the mean time I will start (re-)reading this vscsi thing...

Wei.

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.