On 06/17/2009 11:33 AM, Mark McLoughlin wrote: >> I particularly don't like the idea of arcane machine-dependent slot >> allocation knowledge living in libvirt, because it needs to be in Qemu >> anyway for non-libvirt users. No point in having two implementations >> of something tricky and likely to have machine quirks, if one will do. >> > > Indeed. >
I don't understand this. Management already has to allocate MAC addresses, UUIDs, IDE interface and master/slave role, SCSI LUNs/targets/whatever. It has to understand NUMA (if not do actual allocation). Even if it doesn't allocate the slots, it has to be able to query them so it can tell the user which NIC or controller is connected where, or to do hotunplug. It has to understand that there is a limitation on the number of slots, and know what that limitation is (unless it feels that launching an overcommitted guest and showing an error to the user is preferable to not allowing the user to overcommit in the first place. If you'll review my patent application for pci slot allocation, you'll see the following line: slot_nr = nb_allocated_slots++; /* Allocate pci slot */ while there is a lot of complicated setup code before that (see the prior art section as well), I believe licensees could well implement the algorithm in two short months, including testing. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. _______________________________________________ Virtualization mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/virtualization
