Re: [Xen-devel] [PATCH v3 8/8] RFC: Sketch constructors, DomainCreateNew

[Nick Rosbrook <rosbrookn@gmail.com>]

> I think marshaling and unmarshalling should be fine, *as long as* the
> structure being unmarshalled actually went through the
> libxl_<type>_init() function first.
>
> In fact, I was kicking around the idea of adding a non-exported field to
> all the generated structs -- maybe "bool initalized" -- and having the
> .fromC() methods set this to 'true', and the .toC() methods return an
> error if it wasn't set.  But then we'd need to write custom JSON
> marshallers to handle these.

I *think* to guarantee that libxl_<type>_init() has been called when
unmarshaling, we would need to generate UnmarshalJSON functions to
implement json.Unmarshaler. E.g.,:

func (dd *DeviceDisk) UnmarshalJSON(data []byte) error {
        if dd == nil { // Or maybe this is the 'initialized' check you mentioned
                dd, err := NewDeviceDisk()
                if err != nil {
                        return err
                }
        }

        return json.Unmarshal(data, dd)
}

AFAICT, this would be required for someone to unmarshal a complete
domain configuration in one go.

> I'm not personally very interested in parsing xl.cfg files, but libxl
> has library functions to do that, so it should be something very easy to
> add if you want.  (Although in fact, it looks like a lot of the code to
> actually interpret the results of the parsing is in xl; we might want to
> see about moving some of that functionality into libxlu.)

Okay, noted.

> > If we stick with this outline for constructors, they will be easy to
> > generate. I'm happy to work on that, unless you were already planning
> > on it.
>
> I'm afraid my 1 day a week of coding is going to have to be diverted to
> something else for a month or so; so please go ahead if you have the time.

Okay, I think I can manage this fairly easily.

> As far as further steps -- do you have a clear idea what kind of
> functionality you'd like to see possible by the time of the feature
> freeze (probably in May)?  Do you have plans to use these bindings
> yourself, and if so, how?
>
> For my part, I want to start and reap guests.  The latter will require
> adding event callback functionality which will require more thought (and
> perhaps expose more libxl issues).  But I don't yet have a clear target
> beyond that.

Yes, I plan on using these bindings in redctl (our Redfield toolstack)
[1], to replace our os/exec calls to xl. To fully make that
transition, we would need domain start/stop, PCI and network
attach/detach, as well as some utilities (most of which are either
implemented, or would be easy to do). But, making that transition is
relatively low on the priority list right now, so I can't commit to a
timeline unfortunately.

> Re function calls -- do we want to just manually duplicate them as
> needed, or try to get some sort of IDL support?

I think it will make more sense to manually duplicate them as needed.
That way, we can be more particular about function signatures etc. to
ensure they are idiomatic Go. Also, I am of the opinion that a minimal
API is a better place to start. Which brings me to another question
and potential work item:

Do we want to re-evaluate what is currently implemented in the API? Do
you have plans to use everything that is currently there? If not, it
might be nice to trim off things we don't need right now.

> Other work items include:
>
> * modifying configure to detect the availability of go and enable the
> bindings if it's available
>
> * Enabling go build testing in the gitlab CI loop
>
> * Making `go get` work, which might involve having code to push
> post-generated code to a repo and tagging as appropriate

I was going to ask about this. You had a vanity URL in place at one
point, right? Did `go get` ever work with that? In any case, pushing
to another repo might be desirable.

Thanks,
-NR

[1] https://gitlab.com/redfield/redctl

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel