On Tue, Jul 17, 2012 at 03:59:20PM +0200, Marc-André Lureau wrote: > On Tue, Jul 17, 2012 at 3:53 PM, Christophe Fergeau <[email protected]> > wrote: > >> and I guess we rely on lower level of the stack to do that for us. > > > > Except I'm not sure any part of the stack is doing this for us, is there > > such a part? In this specific case, the protocol can handle an arbitrary > > That would be tcp & ssl in our case. > > > number of monitors as I understand it, it's the client code that cannot > > handle too many monitors, so limiting the number of monitors here would > > make sense. > > It's an issue I wanted to raise, I'm not saying this must be fixed in this > > patch. > > I can't think of a reasonable way of handling that, except having > limitation of max monitors == number of monitors on client side. This > would be a logical change, except that it will not allow, for > instance, to work with multi-display on a single monitor (like I do > now, but perhaps this is only interesting for developpers)
Oh, I was mostly thinking of checking max_monitors for an arbitrary max value (4, 16 or 256) to avoid allocating arbitrary amount of memory by trusting a network value. Christophe
pgp788Ba2gfXZ.pgp
Description: PGP signature
_______________________________________________ virt-tools-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/virt-tools-list
