From: Juergen Gross <jgross@suse.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: wei.liu2@citrix.com, xen-devel@lists.xen.org
Subject: Re: [PATCH 0/3] libxl: add framework for device types
Date: Wed, 6 Jul 2016 14:55:02 +0200 [thread overview]
Message-ID: <577CFFA6.5000104@suse.com> (raw)
In-Reply-To: <22396.64978.24502.488069@mariner.uk.xensource.com>
On 06/07/16 14:47, Ian Jackson wrote:
> Juergen Gross writes ("Re: [PATCH 0/3] libxl: add framework for device types"):
>> On 06/07/16 13:04, Ian Jackson wrote:
>>>> + for (i = 0; i < d_config->num_pcidevs; i++) {
>>>> + rc = libxl__device_pci_add(gc, domid, &d_config->pcidevs[i], 1);
>>>> + if (rc < 0) {
>>>> + LOG(ERROR, "libxl_device_pci_add failed: %d", rc);
>>>> + goto out;
>>>> + }
>>>> + }
>>>> +
>>>
>>> And there is similar code in 3/3 for dtdevs. Could that be lifted
>>> away somehow ? (You'd have to take some care about the types, sadly;
>>> ie, I think libxl__device_pci_add might have to start to take a
>>> void*; maybe some macros could make things typesafe?)
>>
>> I thought about this idea already. I think we would end up with more
>> code which would be rather unpleasant to read. Main reason is the
>> need for a dtdev wrapper function and the pci backend creation.
>
> I'm not sure what you mean by dtdev wrapper function.
The loop for dtdev calls a xc_ function with different parameters than
the one for pci. We'd need a libxl__device_dtdev_add() wrapper function
to do the xc_ call.
> As for pci backend, there could be a separate hook for "after adding
> all devices of this type".
Right. And summing up the additional hooks and queries whether they
are specified sums up to more overhead than the current version.
> But if you don't think this is feasible I won't insist on it. The
> approach you have is already a big improvement.
Thanks.
I'm planning to add more to it (e.g. I'd like to get rid of the
MERGE() macro in libxl_retrieve_domain_configuration() in favor of a
device type hook in order to be able to have _all_ stuff for one type
in one source file.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-07-06 12:55 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-21 14:24 [PATCH 0/3] libxl: add framework for device types Juergen Gross
2016-06-21 14:24 ` [PATCH 1/3] " Juergen Gross
2016-06-21 14:24 ` [PATCH 2/3] libxl: refactor domcreate_attach_pci() to use device type framework Juergen Gross
2016-06-21 14:24 ` [PATCH 3/3] libxl: refactor domcreate_attach_dtdev() " Juergen Gross
2016-07-04 10:26 ` [PATCH 0/3] libxl: add framework for device types Juergen Gross
2016-07-06 11:04 ` Ian Jackson
2016-07-06 12:40 ` Juergen Gross
2016-07-06 12:47 ` Ian Jackson
2016-07-06 12:55 ` Juergen Gross [this message]
2016-07-06 16:09 ` 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=577CFFA6.5000104@suse.com \
--to=jgross@suse.com \
--cc=ian.jackson@eu.citrix.com \
--cc=wei.liu2@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.