On Mon, Oct 05, 2015 at 16:01:06 +0200, Andrea Bolognani wrote:
> On Mon, 2015-10-05 at 15:24 +0200, Jiri Denemark wrote:
> > On Mon, Oct 05, 2015 at 14:13:05 +0200, Andrea Bolognani wrote:
> > > ---
> > > This pushes a lot of lines well beyond 80 columns, but then again
> > > some
> > > of the entries were already as long as 92 columns...
> > >
> > > src/qemu/qemu_capabilities.h | 412 +++++++++++++++++++++----------
> > > ------------
> > > 1 file changed, 205 insertions(+), 207 deletions(-)
> >
> > Hmm, could we also finally get rid of the useless explicit numbering
> > and
> > make the list similar to the strings in qemu_capabilities.c? All of
> > these are internal flags, so the numbers are pretty much irrelevant
> > as
> > long as the items correspond to the correct string representation.
>
> Either doing away with the spacing or removing the explicit
> values works for me, as either would look better than the
> current mess.
>
> Would removing the values altogether cause any trouble with
> the following values, that would have to remain defined
> explicitly?
>
> QEMU_CAPS_NET_NAME = QEMU_CAPS_0_10
> QEMU_CAPS_HOST_NET_ADD = QEMU_CAPS_0_10
Oh, that's a real mess. Normally, if some caps are implied by another
one, we handle that in the corresponding probing function. But in this
case these are not separate capabilities, we still have just one
capability, but there are three symbolic names leading to it. I think
the simplest solution of this mess is just
#define QEMU_CAPS_NET_NAME QEMU_CAPS_0_10
#define QEMU_CAPS_HOST_NET_ADD QEMU_CAPS_0_10
and only keep QEMU_CAPS_0_10 in the enum.
Jirka
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list