Libguestfs - Oct 2020 - Re: [PATCH libnbd 1/5] common/utils: Copy simple vector library from nbdkit.

On 10/27/20 1:38 PM, Richard W.M. Jones wrote:
> This library proved useful in nbdkit where we need to construct an
> array or vector of arbitrary objects, with the easy ability to append
> at the end.  Wherever code uses realloc(3) to build an array of
> objects is a candidate for replacement by this library.
> ---
>  Makefile.am              |   1 +
>  common/utils/Makefile.am |  44 ++++++++++
>  common/utils/vector.c    |  51 +++++++++++
>  common/utils/vector.h    | 177 +++++++++++++++++++++++++++++++++++++++
>  configure.ac             |   1 +
>  5 files changed, 274 insertions(+)
> 
> +++ b/common/utils/Makefile.am
> @@ -0,0 +1,44 @@
> +# nbdkit
> +# Copyright (C) 2019 Red Hat Inc.
> +#
> +# Redistribution and use in source and binary forms, with or without
> +# modification, are permitted provided that the following conditions are
> +# met:
Since we are lifting straight from nbdkit, this is fine (our one-way
license conversion at play).  It does mean we have a risk in the
opposite direction (any improvement made here can't easily be pushed
back to nbdkit unless the author is okay with the difference in license).

As long as we are lifting this, should we also list automatic cleanup
usage, where we then demand modern gcc/clang as compiler?

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

On Tue, Oct 27, 2020 at 01:48:31PM -0500, Eric Blake
wrote:
> On 10/27/20 1:38 PM, Richard W.M. Jones wrote:
> > This library proved useful in nbdkit where we need to construct an
> > array or vector of arbitrary objects, with the easy ability to append
> > at the end.  Wherever code uses realloc(3) to build an array of
> > objects is a candidate for replacement by this library.
> > ---
> >  Makefile.am              |   1 +
> >  common/utils/Makefile.am |  44 ++++++++++
> >  common/utils/vector.c    |  51 +++++++++++
> >  common/utils/vector.h    | 177
+++++++++++++++++++++++++++++++++++++++
> >  configure.ac             |   1 +
> >  5 files changed, 274 insertions(+)
> > 
> 
> > +++ b/common/utils/Makefile.am
> > @@ -0,0 +1,44 @@
> > +# nbdkit
> > +# Copyright (C) 2019 Red Hat Inc.
> > +#
> > +# Redistribution and use in source and binary forms, with or without
> > +# modification, are permitted provided that the following conditions
are
> > +# met:
> 
> Since we are lifting straight from nbdkit, this is fine (our one-way
> license conversion at play).  It does mean we have a risk in the
> opposite direction (any improvement made here can't easily be pushed
> back to nbdkit unless the author is okay with the difference in license).
I think we're OK as long as we keep the BSD-ish license on these
files?  That way changes made to these files (only) would be under the
same license as nbdkit.  Of course we end up with a franken-license
but at least it's not as bad as QEMU (!) and the whole thing should
still be LGPLv2+  (AIUI/IANAL/E&OE/...)
> As long as we are lifting this, should we also list automatic cleanup
> usage, where we then demand modern gcc/clang as compiler?
While I don't object to it, I didn't need automatic cleanup for this
patch so I didn't copy that one across.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW

On Tue, Oct 27, 2020 at 07:37:27PM +0000, Richard W.M. Jones
wrote:
> On Tue, Oct 27, 2020 at 01:48:31PM -0500, Eric Blake wrote:
> > On 10/27/20 1:38 PM, Richard W.M. Jones wrote:
> > > +++ b/common/utils/Makefile.am
> > > @@ -0,0 +1,44 @@
> > > +# nbdkit
> > > +# Copyright (C) 2019 Red Hat Inc.
> > > +#
> > > +# Redistribution and use in source and binary forms, with or
without
> > > +# modification, are permitted provided that the following
conditions are
> > > +# met:
> > 
> > Since we are lifting straight from nbdkit, this is fine (our one-way
> > license conversion at play).  It does mean we have a risk in the
> > opposite direction (any improvement made here can't easily be
pushed
> > back to nbdkit unless the author is okay with the difference in
license).
> 
> I think we're OK as long as we keep the BSD-ish license on these
> files?  That way changes made to these files (only) would be under the
> same license as nbdkit.  Of course we end up with a franken-license
> but at least it's not as bad as QEMU (!) and the whole thing should
> still be LGPLv2+  (AIUI/IANAL/E&OE/...)
Should add that this is not the first file copied from nbdkit -- see
libnbd.git/common/include/.  We've had a couple of nbdkit files in
there for quite a while.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top