From: Roger Pau Monne <roger.pau@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [PATCH v4 05/10] libxl: convert libxl_device_nic_add to an async operation
Date: Wed, 30 May 2012 10:54:06 +0100 [thread overview]
Message-ID: <4FC5EE3E.5080701@citrix.com> (raw)
In-Reply-To: <20420.57093.469702.580339@mariner.uk.xensource.com>
Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH v4 05/10] libxl: convert libxl_device_nic_add to an async operation"):
>> This patch converts libxl_device_nic_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.
>
> Thanks. I'm afraid this is still tripping my repetition detector.
> See below.
>
>> diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
>> index 6c9bbc2..9933cc2 100644
>> --- a/tools/libxl/libxl_device.c
>> +++ b/tools/libxl/libxl_device.c
>> @@ -444,6 +444,24 @@ void libxl__add_disks(libxl__egc *egc, libxl__ao *ao, uint32_t domid,
>> }
>> }
>>
>> +void libxl__add_nics(libxl__egc *egc, libxl__ao *ao, uint32_t domid,
>> + libxl_domain_config *d_config,
>> + libxl__ao_device **devices,
>> + libxl__device_callback callback)
>> +{
>> + AO_GC;
>> + GCNEW_ARRAY(*devices, d_config->num_vifs);
>> + libxl__ao_device *aodev = *devices;
>> + int i;
>> +
>> + for (i = 0; i< d_config->num_vifs; i++) {
>> + libxl__prepare_ao_device(&aodev[i], ao, devices);
>> + aodev[i].callback = callback;
>> + libxl__device_nic_add(egc, domid,&d_config->vifs[i],
>> +&aodev[i]);
>> + }
>> +}
>
> The same comment applies as before about libxl__add_disks and the two
> loops.
>
>
> But, this is another copy of libxl__add_disks. Perhaps you want a
> macro to generate these functions ?
Yes, a macro would be ok I think.
> In general this patch seems to contain an awful lot of very similar
> code to the previous one. Eg domcreate_nic_connected is practically
> identical to domcreate_disk_connected. And domcreate_attach_nick is
> practically identical to domcreate_attach_disk.
>
>
> Another option would be to make the types of libxl__device_FOO_add
> compatible (by replacing the actual config parameter with const void*)
> and then pass them as function pointers.
>
> Or you could even have a table
> { offsetof(disks, libxl_domain_config), sizeof(libxl_device_disk),
> libxl__device_disk_add },
> { offsetof(vifs, libxl_domain_config), sizeof(libxl_device_vif),
> libxl__device_nic_add },
> ...
> which your domain creation logic could iterate over. That way you
> would do away with domcreate_FOO_connected and you'd end up with
>
> static void domcreate_device_connected(libxl__egc *egc,
> libxl__ao_device *aodev)
> {
>
> tableentry = devicekindstable[dcs->currentdevicekind];
>
> rc = libxl__ao_device_check_last(gc, aodev, dcs->devices,
> dcs->num_devices);
>
> if (rc> 0) return;
> if (rc) {
> LOGE(ERROR, "error connecting devices");
> goto error_out;
> }
>
> dcs->currentdevicekind++;
>
> if (!devicekindstable[dcs->currentdevicekind].add_function) {
> domcreate_complete(egc, dcs, rc);
> } else {
> domcreate_attach_devices(egc, dcs);
> }
>
> or something like it.
We can really iterate over this to add the devices, since we might need
to launch the device model between connecting the disks and connecting
the nics, I will try to find a nicer way to do this, I will try to come
up with some macros to define this in a nicer way.
> Or something. Anyway, can you try to find a way to avoid me having to
> review lots of nearly-identical code ?
>
>
> Thanks,
> Ian.
next prev parent reply other threads:[~2012-05-30 9:54 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-24 10:23 [PATCH v4 0/10] execute hotplug scripts from libxl Roger Pau Monne
2012-05-24 10:23 ` [PATCH v4 01/10] libxl: change libxl__ao_device_remove to libxl__ao_device Roger Pau Monne
2012-05-29 13:32 ` Ian Jackson
2012-05-30 8:43 ` Roger Pau Monne
2012-05-31 11:13 ` Ian Jackson
2012-05-24 10:23 ` [PATCH v4 02/10] libxl: move device model creation prototypes Roger Pau Monne
2012-05-24 10:23 ` [PATCH v4 03/10] libxl: convert libxl_domain_destroy to an async op Roger Pau Monne
2012-05-29 14:04 ` Ian Jackson
2012-05-24 10:23 ` [PATCH v4 04/10] libxl: convert libxl_device_disk_add to an asyn op Roger Pau Monne
2012-05-29 14:26 ` Ian Jackson
2012-05-29 14:40 ` Ian Campbell
2012-05-24 10:24 ` [PATCH v4 05/10] libxl: convert libxl_device_nic_add to an async operation Roger Pau Monne
2012-05-29 14:36 ` Ian Jackson
2012-05-30 9:54 ` Roger Pau Monne [this message]
2012-05-30 10:06 ` Ian Jackson
2012-05-24 10:24 ` [PATCH v4 06/10] libxl: add option to choose who executes hotplug scripts Roger Pau Monne
2012-05-29 14:38 ` Ian Jackson
2012-05-24 10:24 ` [PATCH v4 07/10] libxl: set nic type to VIF by default Roger Pau Monne
2012-05-24 10:24 ` [PATCH v4 08/10] libxl: call hotplug scripts for disk devices from libxl Roger Pau Monne
2012-05-25 15:13 ` Roger Pau Monne
2012-05-29 14:50 ` Ian Jackson
2012-05-30 11:33 ` Roger Pau Monne
2012-05-24 10:24 ` [PATCH v4 09/10] libxl: call hotplug scripts for nic " Roger Pau Monne
2012-05-29 14:57 ` Ian Jackson
2012-05-24 10:24 ` [PATCH v4 10/10] libxl: use libxl__xs_path_cleanup on device_destroy Roger Pau Monne
2012-05-29 14:58 ` Ian Jackson
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=4FC5EE3E.5080701@citrix.com \
--to=roger.pau@citrix.com \
--cc=Ian.Jackson@eu.citrix.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).