All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wei Liu <wei.liu2@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Cc: Ian Jackson <ian.jackson@citrix.com>,
	Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [PATCH 3/5] libxl: add support for vscsi
Date: Wed, 3 Feb 2016 14:36:03 +0000	[thread overview]
Message-ID: <20160203143603.GL23178@citrix.com> (raw)
In-Reply-To: <20160127100012.GA6631@gmail.com>

(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.

  reply	other threads:[~2016-02-03 14:36 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-13 11:59 [PATCH 0/5] libbxl: add support for pvscsi, iteration 6 Olaf Hering
2015-11-13 11:59 ` [PATCH 1/5] vscsiif.h: fix WWN notation for p-dev property Olaf Hering
2015-11-13 11:59 ` [PATCH 2/5] docs: add vscsi to xenstore-paths.markdown Olaf Hering
2015-11-13 11:59 ` [PATCH 3/5] libxl: add support for vscsi Olaf Hering
2016-01-27 10:00   ` Olaf Hering
2016-02-03 14:36     ` Wei Liu [this message]
2016-02-03 14:42       ` Wei Liu
2016-02-03 16:24       ` Olaf Hering
2015-11-13 11:59 ` [PATCH 4/5] vscsiif.h: add some notes about xenstore layout Olaf Hering
2015-11-13 11:59 ` [PATCH 5/5] Scripts to create and delete xen-scsiback nodes in Linux target framework Olaf Hering

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160203143603.GL23178@citrix.com \
    --to=wei.liu2@citrix.com \
    --cc=ian.campbell@citrix.com \
    --cc=ian.jackson@citrix.com \
    --cc=olaf@aepfle.de \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.