On 05/05/2011 11:26 AM, Daniel P. Berrange wrote: > Introduce a new API in libvirt-qemu.so > > virDomainPtr virDomainQemuAttach(virConnectPtr domain, > int pid, > unsigned int flags); Do we want pid_t instead of pid? Or are we guaranteed that this only works on platforms with /proc/nnn, and that all such platforms already have sizeof(pid_t)<=sizeof(int)? I ask because it would be a shame if there is ever a system which supports more than 2G simultaneous processes [pid_t is signed, but negative pids are groups rather than processes], yet we locked ourselves in to a capped pid size. Or, it is quite conceivable for a platform that represents pid_t as the same size as void* (basically, the pointer to the physical memory address in the kernel where the process information is stored), and if such a platform is 64-bits, then even if you can't have 2G simultaneous processes, you still can have large pids. But my guess is that it is not a problem in practice (64-bit Linux uses 4-byte pid_t, and changing that now would be a major ABI change, and most systems, even if they randomize pids rather than assigning the sequentially, still return pids as an index into a kernel array, rather than as an actual kernel pointer). So I guess I'm okay with: ACK. -- 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