> -----Original Message----- > From: Ian Jackson <[email protected]> > Sent: 28 September 2020 14:44 > To: Wei Liu <[email protected]> > Cc: Roger Pau Monné <[email protected]>; Paul Durrant <[email protected]>; xen- > [email protected]; Durrant, Paul <[email protected]>; Anthony > PERARD > <[email protected]> > Subject: RE: [EXTERNAL] [PATCH 2/2] libxl: do not automatically force detach > of block devices > > CAUTION: This email originated from outside of the organization. Do not click > links or open > attachments unless you can confirm the sender and know the content is safe. > > > > Wei Liu writes ("Re: [PATCH 2/2] libxl: do not automatically force detach of > block devices"): > > On Mon, Sep 14, 2020 at 12:41:09PM +0200, Roger Pau Monné wrote: > > > Maybe a new function should be introduced instead, that attempts to > > > remove a device gracefully and fail otherwise? > > > > > > Then none of the current APIs would change, and xl could use this new > > > function to handle VBD removal? > > > > This sounds fine to me. > > I agree. > > If there is going to be different default policy for different devices > it ought to be in xl, not libxl, but frankly I think this is an > anomaly. > > I suggest we have a new entrypoint that specifies the fallback > behaviour explicitly.
Indeed. See v2 of my series, posted a couple of weeks ago, specifically: https://lists.xenproject.org/archives/html/xen-devel/2020-09/msg01029.html > ISTM that there are three possible behaviours: > - fail if the guest does not cooperate That is the newly introduced 'safe_remove' > - fall back to force remove That is the existing 'remove' > - rip the device out immediately That is the existing 'destroy' > The last of these would be useful only in rare situations. IDK if the > length of the timeout (for the first two cases) ought to be a > parameter too. > I think that would be a worthy enhancement but above and beyond the aim of this series. Paul
