[PATCH 4/6] tools/libs: add a new libxenmanage library

Juergen Gross posted 6 patches 1 month, 1 week ago
[PATCH 4/6] tools/libs: add a new libxenmanage library
Posted by Juergen Gross 1 month, 1 week ago
In order to have a stable interface in user land for using stable
domctl and possibly later sysctl interfaces, add a new library
libxenmanage.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
V1:
- new patch
---
 tools/include/xenmanage.h          |  98 +++++++++++++++++
 tools/libs/Makefile                |   1 +
 tools/libs/manage/Makefile         |  10 ++
 tools/libs/manage/Makefile.common  |   1 +
 tools/libs/manage/core.c           | 170 +++++++++++++++++++++++++++++
 tools/libs/manage/libxenmanage.map |   8 ++
 tools/libs/uselibs.mk              |   2 +
 7 files changed, 290 insertions(+)
 create mode 100644 tools/include/xenmanage.h
 create mode 100644 tools/libs/manage/Makefile
 create mode 100644 tools/libs/manage/Makefile.common
 create mode 100644 tools/libs/manage/core.c
 create mode 100644 tools/libs/manage/libxenmanage.map

diff --git a/tools/include/xenmanage.h b/tools/include/xenmanage.h
new file mode 100644
index 0000000000..2e6c3dedaa
--- /dev/null
+++ b/tools/include/xenmanage.h
@@ -0,0 +1,98 @@
+/*
+ * Copyright (c) 2024 SUSE Software Solutions Germany GmbH
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; If not, see <http://www.gnu.org/licenses/>.
+ */
+#ifndef XENMANAGE_H
+#define XENMANAGE_H
+
+#include <stdint.h>
+
+/* Callers who don't care don't need to #include <xentoollog.h> */
+struct xentoollog_logger;
+
+typedef struct xenmanage_handle xenmanage_handle;
+
+/*
+ * Open libxenmanage.
+ *
+ * Get a handle of the xenmanage library. The handle is required for all
+ * further operations of the library.
+ * Parameters:
+ *   logger:     Logging function to use. If NULL logging is done to stderr.
+ *   open_flags: Only 0 supported.
+ * Return value: Handle or NULL if error.
+ */
+xenmanage_handle *xenmanage_open(struct xentoollog_logger *logger,
+                                 unsigned int open_flags);
+
+/*
+ * Close libxenmanage.
+ *
+ * Return a handle of the xenmanage library.
+ * Parameters:
+ *    hdl: Handle obtained by xenmanage_open().
+ * Return value: always 0.
+ */
+int xenmanage_close(xenmanage_handle *hdl);
+
+#define XENMANAGE_GETDOMSTATE_STATE_EXIST     0x0001  /* Domain is existing. */
+#define XENMANAGE_GETDOMSTATE_STATE_SHUTDOWN  0x0002  /* Shutdown finished. */
+#define XENMANAGE_GETDOMSTATE_STATE_DYING     0x0004  /* Domain dying. */
+
+/*
+ * Return state information of an existing domain.
+ *
+ * Returns the domain state and unique id of the given domain.
+ * Parameters:
+ *   hdl:       handle returned by xenmanage_open()
+ *   domid:     domain id of the domain to get the information for
+ *   state:     where to store the state (XENMANAGE_GETDOMSTATE_STATE_ flags,
+ *              nothing stored if NULL)
+ *   unique_id: where to store the unique id of the domain (nothing stored if
+ *              NULL)
+ * Return value: 0 if information was stored, -1 else (errno is set)
+ */
+int xenmanage_get_domain_info(xenmanage_handle *hdl, unsigned int domid,
+                              unsigned int *state, uint64_t *unique_id);
+
+/*
+ * Return information of a domain having changed state recently.
+ *
+ * Returns the domain id, state and unique id of a domain having changed
+ * state (any of the state bits was modified) since the last time information
+ * for that domain was returned by this function. Only usable by callers who
+ * have registered the VIRQ_DOM_EXC event (normally Xenstore).
+ * Parameters:
+ *   hdl:       handle returned by xenmanage_open()
+ *   domid:     where to store the domid of the domain (not NULL)
+ *   state:     where to store the state (XENMANAGE_GETDOMSTATE_STATE_ flags,
+ *              nothing stored if NULL)
+ *   unique_id: where to store the unique id of the domain (nothing stored if
+ *              NULL)
+ * Return value: 0 if information was stored, -1 else (errno is set)
+ */
+int xenmanage_get_changed_domain(xenmanage_handle *hdl, unsigned int *domid,
+                                 unsigned int *state, uint64_t *unique_id);
+#endif /* XENMANAGE_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libs/Makefile b/tools/libs/Makefile
index 1afcd12e2b..d39516c1b3 100644
--- a/tools/libs/Makefile
+++ b/tools/libs/Makefile
@@ -12,6 +12,7 @@ SUBDIRS-y += devicemodel
 SUBDIRS-y += ctrl
 SUBDIRS-y += guest
 SUBDIRS-y += hypfs
+SUBDIRS-y += manage
 SUBDIRS-y += store
 SUBDIRS-y += stat
 SUBDIRS-$(CONFIG_Linux) += vchan
diff --git a/tools/libs/manage/Makefile b/tools/libs/manage/Makefile
new file mode 100644
index 0000000000..dbfe70d259
--- /dev/null
+++ b/tools/libs/manage/Makefile
@@ -0,0 +1,10 @@
+XEN_ROOT = $(CURDIR)/../../..
+include $(XEN_ROOT)/tools/Rules.mk
+
+MAJOR    = 1
+MINOR    = 0
+version-script := libxenmanage.map
+
+include Makefile.common
+
+include $(XEN_ROOT)/tools/libs/libs.mk
diff --git a/tools/libs/manage/Makefile.common b/tools/libs/manage/Makefile.common
new file mode 100644
index 0000000000..d9efe3462e
--- /dev/null
+++ b/tools/libs/manage/Makefile.common
@@ -0,0 +1 @@
+OBJS-y  += core.o
diff --git a/tools/libs/manage/core.c b/tools/libs/manage/core.c
new file mode 100644
index 0000000000..0c9199f829
--- /dev/null
+++ b/tools/libs/manage/core.c
@@ -0,0 +1,170 @@
+/*
+ * Copyright (c) 2024 SUSE Software Solutions Germany GmbH
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#define __XEN_TOOLS__ 1
+
+#define _GNU_SOURCE
+
+#include <errno.h>
+#include <stdlib.h>
+#include <string.h>
+
+#include <xentoollog.h>
+#include <xenmanage.h>
+#include <xencall.h>
+#include <xentoolcore_internal.h>
+
+#include <xen/xen.h>
+#include <xen/domctl.h>
+
+struct xenmanage_handle {
+    xentoollog_logger *logger, *logger_tofree;
+    unsigned int flags;
+    xencall_handle *xcall;
+};
+
+xenmanage_handle *xenmanage_open(xentoollog_logger *logger,
+                                 unsigned open_flags)
+{
+    xenmanage_handle *hdl = calloc(1, sizeof(*hdl));
+    int saved_errno;
+
+    if ( !hdl )
+        return NULL;
+
+    if ( open_flags )
+    {
+        errno = EINVAL;
+        goto err;
+    }
+
+    hdl->flags = open_flags;
+    hdl->logger = logger;
+    hdl->logger_tofree = NULL;
+
+    if ( !hdl->logger )
+    {
+        hdl->logger = hdl->logger_tofree =
+            (xentoollog_logger *)
+            xtl_createlogger_stdiostream(stderr, XTL_PROGRESS, 0);
+        if ( !hdl->logger )
+            goto err;
+    }
+
+    hdl->xcall = xencall_open(hdl->logger, 0);
+    if ( !hdl->xcall )
+        goto err;
+
+    return hdl;
+
+err:
+    saved_errno = errno;
+    xenmanage_close(hdl);
+    errno = saved_errno;
+
+    return NULL;
+}
+
+int xenmanage_close(xenmanage_handle *hdl)
+{
+    if ( !hdl )
+        return 0;
+
+    xencall_close(hdl->xcall);
+    xtl_logger_destroy(hdl->logger_tofree);
+    free(hdl);
+    return 0;
+}
+
+static int xenmanage_do_domctl_get_domain_state(xenmanage_handle *hdl,
+                                                unsigned int domid_in,
+                                                unsigned int *domid_out,
+                                                unsigned int *state,
+                                                uint64_t *unique_id)
+{
+    struct xen_domctl *buf;
+    struct xen_domctl_get_domain_state *st;
+    int saved_errno;
+    int ret;
+
+    buf = xencall_alloc_buffer(hdl->xcall, sizeof(*buf));
+    if ( !buf )
+    {
+        errno = ENOMEM;
+        return -1;
+    }
+
+    memset(buf, 0, sizeof(*buf));
+
+    buf->cmd = XEN_DOMCTL_get_domain_state;
+    buf->interface_version = XEN_DOMCTL_GETDOMSTATE_VERS_MAX;
+    buf->domain = domid_in;
+
+    ret = xencall1(hdl->xcall, __HYPERVISOR_domctl, (unsigned long)buf);
+    saved_errno = errno;
+    if ( !ret )
+    {
+        st = &buf->u.get_domain_state;
+
+        if ( domid_out )
+            *domid_out = st->domid;
+        if ( state )
+        {
+            *state = 0;
+            if ( st->state & XEN_DOMCTL_GETDOMSTATE_STATE_EXIST )
+                *state |= XENMANAGE_GETDOMSTATE_STATE_EXIST;
+            if ( st->state & XEN_DOMCTL_GETDOMSTATE_STATE_SHUTDOWN )
+                *state |= XENMANAGE_GETDOMSTATE_STATE_SHUTDOWN;
+            if ( st->state & XEN_DOMCTL_GETDOMSTATE_STATE_DYING )
+                *state |= XENMANAGE_GETDOMSTATE_STATE_DYING;
+        }
+        if ( unique_id )
+            *unique_id = st->unique_id;
+    }
+
+    xencall_free_buffer(hdl->xcall, buf);
+
+    errno = saved_errno;
+
+    return ret;
+}
+
+int xenmanage_get_domain_info(xenmanage_handle *hdl, unsigned int domid,
+                              unsigned int *state, uint64_t *unique_id)
+{
+    if ( !hdl || domid >= DOMID_FIRST_RESERVED )
+    {
+        errno = EINVAL;
+        return -1;
+    }
+
+    return xenmanage_do_domctl_get_domain_state(hdl, domid, NULL, state,
+                                                unique_id);
+}
+
+int xenmanage_get_changed_domain(xenmanage_handle *hdl, unsigned int *domid,
+                                 unsigned int *state, uint64_t *unique_id)
+{
+    if ( !hdl || !domid )
+    {
+        errno = EINVAL;
+        return -1;
+    }
+
+    return xenmanage_do_domctl_get_domain_state(hdl, DOMID_INVALID, domid,
+                                                state, unique_id);
+}
diff --git a/tools/libs/manage/libxenmanage.map b/tools/libs/manage/libxenmanage.map
new file mode 100644
index 0000000000..65ec76f882
--- /dev/null
+++ b/tools/libs/manage/libxenmanage.map
@@ -0,0 +1,8 @@
+VERS_1.0 {
+	global:
+		xenmanage_open;
+		xenmanage_close;
+		xenmanage_get_domain_info;
+		xenmanage_get_changed_domain;
+	local: *; /* Do not expose anything by default */
+};
diff --git a/tools/libs/uselibs.mk b/tools/libs/uselibs.mk
index 7aa8d83e06..c0a234cfec 100644
--- a/tools/libs/uselibs.mk
+++ b/tools/libs/uselibs.mk
@@ -16,6 +16,8 @@ LIBS_LIBS += devicemodel
 USELIBS_devicemodel := toollog toolcore call
 LIBS_LIBS += hypfs
 USELIBS_hypfs := toollog toolcore call
+LIBS_LIBS += manage
+USELIBS_manage := toollog toolcore call
 LIBS_LIBS += ctrl
 USELIBS_ctrl := toollog call evtchn gnttab foreignmemory devicemodel
 LIBS_LIBS += guest
-- 
2.43.0
Re: [PATCH 4/6] tools/libs: add a new libxenmanage library
Posted by Anthony PERARD 1 week, 4 days ago
Hi Juergen,

On Wed, Oct 23, 2024 at 03:10:03PM +0200, Juergen Gross wrote:
> In order to have a stable interface in user land for using stable
> domctl and possibly later sysctl interfaces, add a new library
> libxenmanage.

What this new library could do? What sort of operation could be added in
the future? Domain creation? I'm trying to get convince that "manage" is
the right name for it.

To me, "manage" could be something higher level to take care of a domain
from it's creation to its demise.

So for this lib have get_domain_info() to query about a single domain,
and get_changed_domain() which seems to be a state synchronisation
operation. (For that second function, it resemble an operation of the
Matrix API calling "https://.../sync" which return all the new event
since the last time it was called. But back to the new function name, a
get* function which returns a different value every time you call it
might not actually be the right name for it, maybe other functions that
do something similar, or at least tell when there's a new event, would
be poll() and select(), so maybe poll_changed_domain() would be slightly
better at describing the kind of function that it is?)

So, those two functions only query about the states of domains, without
making any modification is seems, so is "manage" still the right name?
At least, it both function doesn't seems to fit in existing stable
libraries so having a new one seems the right call. So the name
depends of what other operation could be added to the library, as such,
a description of the library would be nice, but at least thanks for
documenting every functions!

> diff --git a/tools/include/xenmanage.h b/tools/include/xenmanage.h
> new file mode 100644
> index 0000000000..2e6c3dedaa
> --- /dev/null
> +++ b/tools/include/xenmanage.h
> @@ -0,0 +1,98 @@
> +/*
> + * Copyright (c) 2024 SUSE Software Solutions Germany GmbH
> + *
> + * This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation;
> + * version 2.1 of the License.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with this library; If not, see <http://www.gnu.org/licenses/>.

Shall we use SPDX tags instead of this boilerplate?

> + */
> +#ifndef XENMANAGE_H
> +#define XENMANAGE_H
> +
> +#include <stdint.h>
> +
> +/* Callers who don't care don't need to #include <xentoollog.h> */
> +struct xentoollog_logger;

More like, callers who care will need to include xentoollog.h. Here, we
just avoid the need to include xentoollog.h in xenmanage.h by declaring
the minimum.

If every time I wanted to include an header, I needed to figure which
header needed to be include before, that would be very annoying. Often,
headers include the needed headers.

If you want to have a comment, how about "Avoid the need to include
<xentoollog.h>", that way the comment tell why "struct
xentoollog_logger" is here, where it came from, and is more explicit.


> diff --git a/tools/libs/manage/core.c b/tools/libs/manage/core.c
> new file mode 100644
> index 0000000000..0c9199f829
> --- /dev/null
> +++ b/tools/libs/manage/core.c
> @@ -0,0 +1,170 @@
...
> +
> +#define __XEN_TOOLS__ 1

This define might be better in the Makefile(.common), or even in libs.mk? So far,
only libxenhypfs does define this in source code, all the other defines
are in CFLAGS or there because xenctrl.h is included.


> +static int xenmanage_do_domctl_get_domain_state(xenmanage_handle *hdl,
> +                                                unsigned int domid_in,
> +                                                unsigned int *domid_out,
> +                                                unsigned int *state,
> +                                                uint64_t *unique_id)
> +{
> +    struct xen_domctl *buf;
> +    struct xen_domctl_get_domain_state *st;
> +    int saved_errno;
> +    int ret;
> +
...
> +
> +    ret = xencall1(hdl->xcall, __HYPERVISOR_domctl, (unsigned long)buf);
> +    saved_errno = errno;
> +    if ( !ret )
> +    {
> +        st = &buf->u.get_domain_state;

You could define *st here.
struct xen_domctl_get_domain_state *st = &...;

Or even with ".. *const st" but maybe that's not common enough in C
code.

Cheers,

-- 

Anthony Perard | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech
Re: [PATCH 4/6] tools/libs: add a new libxenmanage library
Posted by Jürgen Groß 1 week, 4 days ago
On 22.11.24 14:55, Anthony PERARD wrote:
> Hi Juergen,
> 
> On Wed, Oct 23, 2024 at 03:10:03PM +0200, Juergen Gross wrote:
>> In order to have a stable interface in user land for using stable
>> domctl and possibly later sysctl interfaces, add a new library
>> libxenmanage.
> 
> What this new library could do? What sort of operation could be added in
> the future? Domain creation? I'm trying to get convince that "manage" is
> the right name for it.

It is thought to encapsulate all (future) stable hypercalls replacing
current sysctl and domctl operations.

> To me, "manage" could be something higher level to take care of a domain
> from it's creation to its demise.

Yes, and to manage the host.

> So for this lib have get_domain_info() to query about a single domain,
> and get_changed_domain() which seems to be a state synchronisation
> operation. (For that second function, it resemble an operation of the
> Matrix API calling "https://.../sync" which return all the new event
> since the last time it was called. But back to the new function name, a
> get* function which returns a different value every time you call it
> might not actually be the right name for it, maybe other functions that
> do something similar, or at least tell when there's a new event, would
> be poll() and select(), so maybe poll_changed_domain() would be slightly
> better at describing the kind of function that it is?)

Fine with me. I'm always in favor of descriptive names.

> So, those two functions only query about the states of domains, without
> making any modification is seems, so is "manage" still the right name?
> At least, it both function doesn't seems to fit in existing stable
> libraries so having a new one seems the right call. So the name
> depends of what other operation could be added to the library, as such,
> a description of the library would be nice, but at least thanks for
> documenting every functions!

I can add more comments, of course. This was just a first iteration to
get some feedback whether the general approach is okay.

> 
>> diff --git a/tools/include/xenmanage.h b/tools/include/xenmanage.h
>> new file mode 100644
>> index 0000000000..2e6c3dedaa
>> --- /dev/null
>> +++ b/tools/include/xenmanage.h
>> @@ -0,0 +1,98 @@
>> +/*
>> + * Copyright (c) 2024 SUSE Software Solutions Germany GmbH
>> + *
>> + * This library is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU Lesser General Public
>> + * License as published by the Free Software Foundation;
>> + * version 2.1 of the License.
>> + *
>> + * This library is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>> + * Lesser General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU Lesser General Public
>> + * License along with this library; If not, see <http://www.gnu.org/licenses/>.
> 
> Shall we use SPDX tags instead of this boilerplate?

My thinking was to avoid that for "official" header files, as those might
be copied verbatim to other projects, which might not use SPDX. So having
the license text verbatim avoids any problems in this regard.

> 
>> + */
>> +#ifndef XENMANAGE_H
>> +#define XENMANAGE_H
>> +
>> +#include <stdint.h>
>> +
>> +/* Callers who don't care don't need to #include <xentoollog.h> */
>> +struct xentoollog_logger;
> 
> More like, callers who care will need to include xentoollog.h. Here, we
> just avoid the need to include xentoollog.h in xenmanage.h by declaring
> the minimum.
> 
> If every time I wanted to include an header, I needed to figure which
> header needed to be include before, that would be very annoying. Often,
> headers include the needed headers.
> 
> If you want to have a comment, how about "Avoid the need to include
> <xentoollog.h>", that way the comment tell why "struct
> xentoollog_logger" is here, where it came from, and is more explicit.

Okay.

>> diff --git a/tools/libs/manage/core.c b/tools/libs/manage/core.c
>> new file mode 100644
>> index 0000000000..0c9199f829
>> --- /dev/null
>> +++ b/tools/libs/manage/core.c
>> @@ -0,0 +1,170 @@
> ...
>> +
>> +#define __XEN_TOOLS__ 1
> 
> This define might be better in the Makefile(.common), or even in libs.mk? So far,
> only libxenhypfs does define this in source code, all the other defines
> are in CFLAGS or there because xenctrl.h is included.

Yes, that's better.

>> +static int xenmanage_do_domctl_get_domain_state(xenmanage_handle *hdl,
>> +                                                unsigned int domid_in,
>> +                                                unsigned int *domid_out,
>> +                                                unsigned int *state,
>> +                                                uint64_t *unique_id)
>> +{
>> +    struct xen_domctl *buf;
>> +    struct xen_domctl_get_domain_state *st;
>> +    int saved_errno;
>> +    int ret;
>> +
> ...
>> +
>> +    ret = xencall1(hdl->xcall, __HYPERVISOR_domctl, (unsigned long)buf);
>> +    saved_errno = errno;
>> +    if ( !ret )
>> +    {
>> +        st = &buf->u.get_domain_state;
> 
> You could define *st here.
> struct xen_domctl_get_domain_state *st = &...;
> 
> Or even with ".. *const st" but maybe that's not common enough in C
> code.

Okay, I'll move the definition down.


Juergen
Re: [PATCH 4/6] tools/libs: add a new libxenmanage library
Posted by Anthony PERARD 1 week ago
On Fri, Nov 22, 2024 at 04:12:25PM +0100, Jürgen Groß wrote:
> On 22.11.24 14:55, Anthony PERARD wrote:
> > On Wed, Oct 23, 2024 at 03:10:03PM +0200, Juergen Gross wrote:
> > > diff --git a/tools/include/xenmanage.h b/tools/include/xenmanage.h
> > > new file mode 100644
> > > index 0000000000..2e6c3dedaa
> > > --- /dev/null
> > > +++ b/tools/include/xenmanage.h
> > > @@ -0,0 +1,98 @@
> > > +/*
> > > + * Copyright (c) 2024 SUSE Software Solutions Germany GmbH
> > > + *
> > > + * This library is free software; you can redistribute it and/or
> > > + * modify it under the terms of the GNU Lesser General Public
> > > + * License as published by the Free Software Foundation;
> > > + * version 2.1 of the License.
> > > + *
> > > + * This library is distributed in the hope that it will be useful,
> > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> > > + * Lesser General Public License for more details.
> > > + *
> > > + * You should have received a copy of the GNU Lesser General Public
> > > + * License along with this library; If not, see <http://www.gnu.org/licenses/>.
> > 
> > Shall we use SPDX tags instead of this boilerplate?
> 
> My thinking was to avoid that for "official" header files, as those might
> be copied verbatim to other projects, which might not use SPDX. So having
> the license text verbatim avoids any problems in this regard.

Well, this header in particular would be fairly useless, I believe, if it
was copied into an other project, it described a library so need to be
distributed along side the library. Second, this isn't the text of the
license but something describing which license is used and where to
find the text for it. An SPDX tag does nearly the same thing, but can
actually be parse by a computer.

Official headers that would be useful to be copied into other project
already expose the SPDX tags, many/all the headers in
xen/include/public, as well as headers created by `mkheader.py` in this
directory (tools/include).

I've taken a look into my directory "/usr/include", and they are plenty
of headers having the SPDX tag.

So overall, I think we are fine to use SPDX tags here as well. ;-)

Cheers,

-- 

Anthony Perard | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech
Re: [PATCH 4/6] tools/libs: add a new libxenmanage library
Posted by Jürgen Groß 2 days, 2 hours ago
On 26.11.24 17:44, Anthony PERARD wrote:
> On Fri, Nov 22, 2024 at 04:12:25PM +0100, Jürgen Groß wrote:
>> On 22.11.24 14:55, Anthony PERARD wrote:
>>> On Wed, Oct 23, 2024 at 03:10:03PM +0200, Juergen Gross wrote:
>>>> diff --git a/tools/include/xenmanage.h b/tools/include/xenmanage.h
>>>> new file mode 100644
>>>> index 0000000000..2e6c3dedaa
>>>> --- /dev/null
>>>> +++ b/tools/include/xenmanage.h
>>>> @@ -0,0 +1,98 @@
>>>> +/*
>>>> + * Copyright (c) 2024 SUSE Software Solutions Germany GmbH
>>>> + *
>>>> + * This library is free software; you can redistribute it and/or
>>>> + * modify it under the terms of the GNU Lesser General Public
>>>> + * License as published by the Free Software Foundation;
>>>> + * version 2.1 of the License.
>>>> + *
>>>> + * This library is distributed in the hope that it will be useful,
>>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>>>> + * Lesser General Public License for more details.
>>>> + *
>>>> + * You should have received a copy of the GNU Lesser General Public
>>>> + * License along with this library; If not, see <http://www.gnu.org/licenses/>.
>>>
>>> Shall we use SPDX tags instead of this boilerplate?
>>
>> My thinking was to avoid that for "official" header files, as those might
>> be copied verbatim to other projects, which might not use SPDX. So having
>> the license text verbatim avoids any problems in this regard.
> 
> Well, this header in particular would be fairly useless, I believe, if it
> was copied into an other project, it described a library so need to be
> distributed along side the library. Second, this isn't the text of the
> license but something describing which license is used and where to
> find the text for it. An SPDX tag does nearly the same thing, but can
> actually be parse by a computer.
> 
> Official headers that would be useful to be copied into other project
> already expose the SPDX tags, many/all the headers in
> xen/include/public, as well as headers created by `mkheader.py` in this
> directory (tools/include).
> 
> I've taken a look into my directory "/usr/include", and they are plenty
> of headers having the SPDX tag.
> 
> So overall, I think we are fine to use SPDX tags here as well. ;-)

Okay, I'll switch to SPDX.


Juergen