xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
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.

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