From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wei Liu Subject: Re: [PATCH 3/5] libxl: add support for vscsi Date: Wed, 3 Feb 2016 14:36:03 +0000 Message-ID: <20160203143603.GL23178@citrix.com> References: <1447415999-22003-1-git-send-email-olaf@aepfle.de> <1447415999-22003-4-git-send-email-olaf@aepfle.de> <20160127100012.GA6631@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20160127100012.GA6631@gmail.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Olaf Hering Cc: Ian Jackson , Wei Liu , Ian Campbell , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org (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.