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@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org