On Thu, May 05, 2011 at 04:33:06PM -0600, Eric Blake wrote: > 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 didn't want to use pid_t, since that doesn't exist on Windows and we can't assume app developers are using gnulib for portability. > 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). Does anything think is it remotely likely that any common platform will use a 64-bit PID ? I'm sceptical, so I'd think 'int' is fine for the API. Worst case, we have to add another API later > > So I guess I'm okay with: > > ACK. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list