Re: [Xen-devel] [PATCH RFC 59/59] tools/xenlight: Create interface for xenlight info

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On Tue, Jan 3, 2017 at 5:45 PM, Ronald Rojas <ronladred@xxxxxxxxx> wrote:
>> > +/*
>> > +#cgo LDFLAGS: -lxenlight -lyajl
>> > +#include <stdlib.h>
>> > +#include <libxl.h>
>> > +*/
>> > +import "C"
>>
>> I see you switched back to dynamic linking -- any particular reason?
>>
>> We probably need to put a "// FIXME" here saying that we need to
>> generate these compile-time dependencies using pkg-config.
>
> We discussed this on IRC but I'll just restate here that I was not able
> to compile the program through static linking and it would be fine to
> just use dynamic linking for now.
> Since we are doing dynamic linking do we still need to use pkg-config?

Probably at some point, to make it less likely things will ever break
in the future (and as a "consumer" of the file to make sure things
don't break for other users).

>> Or taking the approach of the syscall package, and defining a type:
>>
>> type xlerror int
>>
>> func (e xlerror) Error() {
>>
>> }
>>
>> And making a (private) errors[] array, and re-impleminting Error() from
>> the syscall package.
>>
>> I think I would probably go with the syscall library's approach, since
>> (like it) we are handed a set of pre-existing error numbers.
>>
>> What do you think?
>
> I was actually thinking that taking the approach similiar to bufio would
> be better. It would not be difficult to create individual errors for each
> error number and creating variables for each error would allow users to
> easily compare the error that's returned against specific errors.

You can do this with what the syscall library does as well -- see the
references I linked to.  Filling out my example a bit:

type Error int

const (
    ErrorNonspecific = Error(C.ERROR_NONSPECIFIC)
    ErrorVersion = Error(C.ERROR_VERSION)
    ...
)

var errors = [...]string{
  C.ERROR_NONSPECIFIC:   "Non-specific error",
  C.ERROR_VERSION:   "Wrong version",
 ...
}

func (e Error) Error() {
  if 0 <= int(e) && int(e) < len(errors) {
    s := errors[e]
    if s != "" {
      return s
    }
  }
  return "errno " + itoa(int(e))
}

Now Xenlight.ErrorNonspecific is a const that you can compare an error
to; but if you "string" an error you'll get the error message in the
errors[] table -- the same as what you get from the bufio package.

Another advantage of this method is that there's an easy way to
convert return values from libxl functions into an error (just cast it
directly to Error), and if the caller knows that the error returned is
of type Xenlight.Error, they can cast it back to an int and use it
themselves if they want.

But I think either method will work just fine. :-)

> I've also been thinking about how to do the testing and I think it would
> be good to seperate testing into two parts, testing functions that get
> infomation about the system and functions that change the state of the
> system.
>
> I haven't been able to figure out how to use osstest to use the
> Golang libxl but I think it would still be fine to do unit testing by
> writing C and Go code that get information from a specific fuction(like
> physinfo) and seeing if they produce the same output.
>
> For functions that change the state of the system (like create/destroy
> guests) I think your idea of using a chaos monkey would be good. Maybe
> the general procedure would be something like this:
> 1. Get the complete system information through the functions tested
> in the first part.
> 2. Pick a random operation from a set implemented functions.
> 3. Make changes to the copy of the systems information that we have
> 4. Get the system information again through the golang functions and
> see if this copy of the system information matches the copy we already
> have.
> 5. Repeat as necessary
>
> It will probably take some time to finalize the procedure so I will
> plan to submit it as a seperate patch or with a later patch.

Sounds like a plan.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel