[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [libvirt] [PATCH 07/10] network: new XML to support virtual switch functionality
- From: "Daniel P. Berrange" <berrange redhat com>
- To: Eric Blake <eblake redhat com>
- Cc: libvir-list redhat com, Laine Stump <laine laine org>
- Subject: Re: [libvirt] [PATCH 07/10] network: new XML to support virtual switch functionality
- Date: Thu, 14 Jul 2011 15:08:59 +0100
On Thu, Jul 14, 2011 at 07:32:56AM -0600, Eric Blake wrote:
> On 07/14/2011 03:42 AM, Daniel P. Berrange wrote:
> >>
> >> It turns out that we've used internal-use flags before. See how
> >> libvirt.c filters out flags in both virDomainGetXMLDesc and
> >> virSecretGetValue if the flags are larger than 0xffff, so that it can
> >> start internal flags at 1<<16. Regarding the networking code and our
> >> discussions on whether we should split out a second internalFlags
> >> argument rather than cramming internal and external flags into a single
> >> parameter, I think we should be consistent.
> >
> > The difference is that this was an internal impl detail not exposed
> > in the public headers, so could be removed at any time.
> >
> >> Meanwhile, I've got a patch to libvirt.c; I think virDomainGetXMLDesc
> >> should reject an attempt to pass 1<<16, rather than silently ignore it.
> >
> > No, that would not be a good idea, because libvirt.c is in the code
> > path for the remote client, as well as the server side.
>
> But we don't pass internal flags over the wire.
>
> That is, the only time we use internal flags is from within the same
> executable, where we don't go through daemon/remote.c, and therefore
> don't re-feed the request through src/libvirt.c, therefore are not
> impacted by libvirt.c rejecting internal flags.
>
> > We don't
> > want todo any flag filtering on the remote client side at all, since
> > we can't expect the client & server to be on the same versions. Flag
> > filtering can only be done after dispatch via the internal driver
> > table, eg in QEMU, LXC, etc directly.
>
> That would be a valid concern if we passed internal flags over the wire,
> but we don't.
I'm thinking about the case where a value we currently use for an
internal flag, gets used for a public flag in the future. In that
case, any client side checks for curent internal flags would be
bogus.
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 :|
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]