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

[Nick Rosbrook <rosbrookn@xxxxxxxxx>]

> But the problem I'm worried about is this:
>
> Scenario B
> 1. Make an empty, uninitialized structure, without calling NewType()
> 2. Fill in some fields
> 3. Marshal it into json
> 4. Marshal it out of json (with the same version)
>
> In the case above, step 3 encodes all the known fields with *golang*'s
> zero values, rather than libxl's default values, and so step 4 will
> clobber any defaults written by NewType() with golang zero values again.

One way to solve this would be add struct tags to generated types that
tell JSON to omit zero values when marshaling. I.e.,
`json:",omitempty"`. Then, only fields that were actually set will be
marshaled. And, for Unmarshal to overwrite a field set by NewType(),
it would have to be *explicitly* set by a user. But, that does mean if
a field is set, and happens to be a Go zero value, it will not be
shown in the JSON. That could be a problem itself.

> >> 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.
>
> Sure, nor I; but having a goal always helps, even if it's only best-effort.
>
> Looking at redctl, it seems like actually a pretty full-featured
> toolstack -- that seems like a nice complete target to aim at. :-)

Sounds like a plan to me. :)

> I think we should make sure that things actually work.  The very
> original golang bindings I wrote to be able to control cpupools, so I
> think those functions should stay.  But I'm not sure if anyone's ever
> used ConsoleGetTty.  Like `xl.cfg` parsing, it's the sort of thing that
> *somebody* will probably want eventually; so I'm inclined to say it
> would be less cost to just test it and make sure it works than to remove
> it and re-add it when someone decides they need it.
>
> Did you have anything in particular in mind?

Okay, that's good to know. I don't have anything particular in mind, I
just wanted to pose the question. Since I wasn't around when you first
wrote the bindings, I wasn't aware of the motivations.

> I was sort of thinking what we might do is leave `xenlight` as mostly
> just a plain wrapper around the libxl C functions, as close to what
> might be generated as possible; and then have another package that would
> do something more useful.  For instance, having 'Vm' struct, which could
> be Start()ed, shut down, and so on; and which would keep track of
> if/when the domain died, &c.

That's a good point, it might be nice to create an API that is more
"Go-like" and not as tied to libxl semantically speaking.

> > 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.
> We never actually had a URL in place, no.  I had simply chosen the URL
> based on what would be a good combination of easy to type/remember and
> easy to set up effectively.  (This was after having an informal chat
> with Ian Jackson, who tends to do most of this sort of technical admin
> thing.)  We'd probably want to go back and figure out what kind of
> "interface" is possible, how to do versioning &c, and then work
> backwards from that to get a workflow from the various Xen branches into
> that.

What do you mean by "figure out what kind of interface is possible"?
For versioning, I think it would be nice to adopt Go modules and
follow their semantic versioning recommendations. Have you considered
that route, or any others?

> BTW do you guys have a solution to the "install new tools then reboot"
> issue?  I guess if you have a daemon then it will retain the old version
> of the library until after you reboot?

At the moment, we don't have a solution to that problem as we're
simply calling xl via os/exec. But yes, when we integrate xenlight
into redctl the daemon will retain the old version until reboot.

Thanks,
-NR

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