Re: [libvirt] [PATCH] Increased upper limit on lists of pool names

On Wed, Mar 14, 2012 at 08:42:35PM -0500, Jesse J. Cook wrote: > 256 (8 bits) is insufficient for large scale deployments. 65536 (16 > bits) is a > more appropriate limit and should be sufficient. You are more likely to > run > into other system limitations first, such as the 31998 inode link limit > on > ext3. > --- >  src/remote/remote_protocol.x |    2 +- >  1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/src/remote/remote_protocol.x b/src/remote/remote_protocol.x > index 59774b2..58f0871 100644 > --- a/src/remote/remote_protocol.x > +++ b/src/remote/remote_protocol.x > @@ -103,7 +103,7 @@ const REMOTE_INTERFACE_NAME_LIST_MAX = 256; >  const REMOTE_DEFINED_INTERFACE_NAME_LIST_MAX = 256; > >  /* Upper limit on lists of storage pool names. */ > -const REMOTE_STORAGE_POOL_NAME_LIST_MAX = 256; > +const REMOTE_STORAGE_POOL_NAME_LIST_MAX = 65536; > >  /* Upper limit on lists of storage vol names. */ >  const REMOTE_STORAGE_VOL_NAME_LIST_MAX = 1024; We have to think about what the compatibility implications are for this kind of change. eg what is the behaviour when old client talks to new server, and vica-verca.  It might be fine, but I'd like someone to enumerate the before & after behaviour in all combinations. Regards, 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 :|