[libvirt] [PATCH 1/4] Define a QEMU specific API to attach to a running QEMU process

Daniel P. Berrange berrange at redhat.com
Wed May 11 13:09:32 UTC 2011


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 :|




More information about the libvir-list mailing list