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

Re: [Xen-devel] [PATCH 7/9] libxl: Make killing of device model asynchronous

  • To: Ian Jackson <Ian.Jackson@xxxxxxxxxx>
  • From: George Dunlap <George.Dunlap@xxxxxxxxxx>
  • Date: Fri, 30 Nov 2018 16:12:29 +0000
  • Accept-language: en-GB, en-US
  • Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Wei Liu <wei.liu2@xxxxxxxxxx>
  • Delivery-date: Fri, 30 Nov 2018 16:12:45 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHUg1AZgBZ+MnYQn0+qjGZCZGe4sqVlW4aAgAMcEYA=
  • Thread-topic: [PATCH 7/9] libxl: Make killing of device model asynchronous

> On Nov 28, 2018, at 4:43 PM, Ian Jackson <ian.jackson@xxxxxxxxxx> wrote:
> George Dunlap writes ("[PATCH 7/9] libxl: Make killing of device model 
> asynchronous"):
>> Or at least, give it an asynchronous interface so that we can make it
>> actually asynchronous in subsequent patches.
>> Create state structures and callback function signatures.  Add the
>> state structure to libxl__destroy_domid_state.  Break
>> libxl__destroy_domid down into two functions.
> ...
>> +/* Used to detroy the device model */
>> +_hidden void libxl__destroy_device_model(libxl__egc *egc,
>> +                                         libxl__destroy_devicemodel_state 
>> *ddms);
> I think that comment is rather pointless (but I won't object if you
> really want to keep it).  

Yes; that comment looks rather vestigal.

> Conversely it would be nice to say somewhere
> that ddms->callback may be called reentrantly.

What do you mean by reentrantly?  That libxl__destroy_device_model() may end up 
calling it directly (on this execution stack), rather than arranging for it to 
be called by someone else after returning?


Xen-devel mailing list



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