On 02/09/2011 05:55 AM, Niels de Vos wrote:
>> I'm wondering whether we should just have a separate
method for each combo
>> rather than trying to make one method do everything.
>
> Definitely sounds like the sort of thing where we need an arch-specific
> callback function that can report the correct reservation information
> for that architecture (similar to how we already have arch-specific
> callbacks for computing cpu features).
Okay, makes sense to me. Would extending "struct qemu_arch_info" in
src/qemu/qemu_capabilities.c be suitable enough?
Certainly sounds like the right place.
We could add a function pointer that reserves some PCI-slots where
needed. Currently the table already supports different archs and
machines (machines seems NULL everywhere though).
Any objections if I have a look into adding this functionality there?
(Note, I don't have any no timeframe, it's purely hobby for me.)
Feel free to submit a patch, and to take as long as you need - the
beauty of open source is that everyone scratches their own itches in the
timeframe that they need. When you do post a patch, we'll be sure to
review it based on its merits, and either take it as is or give you
feedback for improving it further.
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library
http://libvirt.org