|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 0/3] libxl: add framework for device types
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@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |