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

Re: [Xen-devel] [PATCH v5 04/10] libxl: convert libxl_device_disk_add to an asyn op



Ian Jackson wrote:
Roger Pau Monne writes ("[PATCH v5 04/10] libxl: convert libxl_device_disk_add to an 
asyn op"):
This patch converts libxl_device_disk_add to an ao operation that
waits for device backend to reach state XenbusStateInitWait and then
marks the operation as completed. This is not really useful now, but
will be used by latter patches that will launch hotplug scripts after
we reached the desired xenbus state.

And:

+/* Internal AO operation to connect a disk device, called by
+ * libxl_device_disk_add and libxl__add_disks. This function calls
+ * libxl__initiate_device_add */
+_hidden void libxl__device_disk_add(libxl__egc *egc, uint32_t domid,
+                                    libxl_device_disk *disk,
+                                    libxl__ao_device *aodev);
+
+/* Arranges that dev will be added to the guest, and the
+ * hotplug scripts will be executed (if necessary). When
+ * this is done (or an error happens), the callback in
+ * aodev->callback will be called.
+ */
+_hidden void libxl__initiate_device_add(libxl__egc*, libxl__ao_device *aodev);

I don't think these comments are coherent.

I think a function which "Arranges that dev will be added to the
guest" is one which does everything necessary - ie, the outermost
entrypoint.

And you're using `internal' here to mean `internal to libxl'.  I think
that's clear from the name (which has `__').  Whereas on first reading
it sounds like you mean `internal to the device adding machinery' -
but `libxl__device_disk_add' is the main entrypoint to that
machinery.

I've used 'internal' here to reflex the difference between libxl_device_disk_add and libxl__device_disk_add, but probably leads to confusion.

And `libxl__initiate_device_add' is the internal helper function.

I think these comments need to be clarified and perhaps
libxl__initiate_device_add needs to be renamed to be clear about what
exactly it is for.  Eg
    /* Initiates the device-kind-independent operations blah blah
    hidden void libxl__initiate_device_add_core(libxl__egc*,
                                    libxl__ao_device *aodev);
or something.

Please do reply suggesting alternative wording

Ian.

Well the order is the following:

libxl__device_{disk/nic}_add (device type dependant function) -> libxl__initiate_device_add (device type independent).

I'm really bad about this naming thing. But the fact is that libxl__initiate_device_add is not a good name, since when we call this function the device is already added (to xenstore), this merely waits for it to reach the desired state and performs the necessary actions to "add" it to the guest (call hotplug scripts). Maybe "connect" is a more appropriate name than "add".

I liked the nomenclature because it follows the same style as libxl__initiate_device_remove, and I think (and I might be wrong) it makes things easier to understand.

_______________________________________________
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®.