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@xxxxxxxxxx +1-801-349-2682 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list