[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 1/4] golang/xenlight: add NameToDomid and DomidToName util functions


  • To: Nick Rosbrook <rosbrookn@xxxxxxxxx>
  • From: George Dunlap <George.Dunlap@xxxxxxxxxx>
  • Date: Wed, 22 Apr 2020 18:07:49 +0000
  • Accept-language: en-GB, en-US
  • Authentication-results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none; spf=None smtp.pra=George.Dunlap@xxxxxxxxxx; spf=Pass smtp.mailfrom=George.Dunlap@xxxxxxxxxx; spf=None smtp.helo=postmaster@xxxxxxxxxxxxxxx
  • Cc: Nick Rosbrook <rosbrookn@xxxxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Ian Jackson <Ian.Jackson@xxxxxxxxxx>
  • Delivery-date: Wed, 22 Apr 2020 18:08:14 +0000
  • Ironport-sdr: dO+AnPLyPDt/m73wRthnYAm16wShCidU4VC56Zua1cub1PHccwiEFdSeqNFUatDDXX33NyURZ4 dz7YWFvv3t6jQcKowk4huhG7J1lTGpMGOyisYTwqz0aPNo1ZMQDeQs6JGKJVYYRykstAgEgDN3 Z49IZ018xraXC2vD9JBpOcJtp7GIs5Od3kQVZ+sNdYMQLeSg86NdkY6ejulSpSR0bjNJCx5tPN Y9pafKiXc2jwYBiQ2WudrAbb36jGmpbYkuHr4DKpgAsPl90O2PgC29/1yICtUW485hcGpHT0uC 47E=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHWERYbx3dgi/1zV0KyTdtBFGxU1KiFXiqA
  • Thread-topic: [PATCH 1/4] golang/xenlight: add NameToDomid and DomidToName util functions


> On Apr 12, 2020, at 11:02 PM, Nick Rosbrook <rosbrookn@xxxxxxxxx> wrote:
> 
> Many exported functions in xenlight require a domid as an argument. Make
> it easier for package users to use these functions by adding wrappers
> for the libxl utility functions libxl_name_to_domid and
> libxl_domid_to_name.
> 
> Signed-off-by: Nick Rosbrook <rosbrookn@xxxxxxxxxxxx>
> ---
> tools/golang/xenlight/xenlight.go | 23 +++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
> 
> diff --git a/tools/golang/xenlight/xenlight.go 
> b/tools/golang/xenlight/xenlight.go
> index 3f1b0baa0c..8492bcec4e 100644
> --- a/tools/golang/xenlight/xenlight.go
> +++ b/tools/golang/xenlight/xenlight.go
> @@ -20,6 +20,7 @@ package xenlight
> #cgo LDFLAGS: -lxenlight -lyajl -lxentoollog
> #include <stdlib.h>
> #include <libxl.h>
> +#include <libxl_utils.h>
> */
> import "C"
> 
> @@ -124,6 +125,28 @@ func (ctx *Context) Close() error {
> 
> type Domid uint32
> 
> +// NameToDomid returns the Domid for a domain, given its name, if it exists.
> +func (Ctx *Context) NameToDomid(name string) (Domid, error) {
> +     var domid C.uint32_t
> +
> +     cname := C.CString(name)
> +     defer C.free(unsafe.Pointer(cname))
> +
> +     if ret := C.libxl_name_to_domid(Ctx.ctx, cname, &domid); ret != 0 {
> +             return ^Domid(0), Error(ret)

libxl.h defines INVALID_DOMID — do we want to define an exported constant with 
the same name and use that here?  (Although part of me wonders if DOMID_INVALID 
would be a better option.)

> +     }
> +
> +     return Domid(domid), nil
> +}
> +
> +// DomidToName returns the name for a domain, given its domid.
> +func (Ctx *Context) DomidToName(domid Domid) string {
> +     cname := C.libxl_domid_to_name(Ctx.ctx, C.uint32_t(domid))
> +     defer C.free(unsafe.Pointer(cname))
> +
> +     return C.GoString(cname)
> +}

It looks to me like if the domid doesn’t exist, libxl_domid_to_name() will 
return NULL; and then DomidToName will return “”.  Is that what we want?

If so, it should probably be documented.

One thing that might be worth pointing out is that both of these functions are 
actually racy: There’s no guarantee that by the time libxl_domid_to_name() 
returns that the domain with that name has died, and another domain with a 
different name has re-used the same domid.  That’s partly why Xen has the whole 
“domain reaper” system, like for Unix processes (which so far isn’t 
implementable yet with the golang wrappers).  I think when we make our “vm” 
library, we’re going to want to try to come up with something like an object 
that makes it easy to avoid this sort of race.

But that’s a discussion for another day. :-)  Everything else looks good, 
thanks.

 -George

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.