Re: [Xen-devel] [PATCH] golang/xenlight: Add libxl_utils support

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 7/19/19 11:24 AM, Nicolas Belouin wrote:
> 
> 
> On 7/19/19 12:09 PM, George Dunlap wrote:
>> On 7/19/19 11:03 AM, Nicolas Belouin wrote:
>>>
>>> On 7/19/19 10:50 AM, George Dunlap wrote:
>>>>> On Jul 19, 2019, at 9:47 AM, George Dunlap <george.dunlap@xxxxxxxxxx> 
>>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> On Jul 19, 2019, at 8:34 AM, Nicolas Belouin <nicolas.belouin@xxxxxxxxx> 
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 7/18/19 11:54 PM, George Dunlap wrote:
>>>>>>> The Go bindings for libxl miss functions from libxl_utils, let's start
>>>>>>> with the simple libxl_domid_to_name and its counterpart
>>>>>>> libxl_name_to_domid.
>>>>>>>
>>>>>>> NB that C.GoString() will return "" if it's passed a NULL; see
>>>>>>> https://github.com/golang/go/issues/32734#issuecomment-506835432
>>>>>>>
>>>>>>> Signed-off-by: Nicolas Belouin <nicolas.belouin@xxxxxxxxx>
>>>>>>> Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxx>
>>>>>>> ---
>>>>>>> v3:
>>>>>>> - Wire into build system
>>>>>>> - Add reference to C.GoString() handling NULL to commit message
>>>>>>>
>>>>>>> Nicolas, could you test to see if this actually works for you?
>>>>>> Tested it, it works.
>>>>>>
>>>>>> I must confess I do not use that import path as the new modules mechanism
>>>>>> introduced in Go1.11 downloads and compile a versioned copy of every
>>>>>> dependency per project, and this behavior is incompatible with the build
>>>>>> system used here.
>>>>> It’s possible that something fundamentally has changed, but I suspect 
>>>>> that rather you don’t quite understand how the current build system is 
>>>>> supposed to work.  (In which case a write-up in the tree would probably 
>>>>> be useful.)
>>>>>
>>>>> Go has always insisted that there be no binary compatibility between 
>>>>> versions; so it’s always been necessary to re-compile all your libraries 
>>>>> when upgrading from (say) 1.8 to 1.9.  Which means that any useable 
>>>>> distribution must also include all the source files necessary to 
>>>>> recompile when you bump the version number.
>>>>>
>>>>> So the core mechanism of the “install” is actually to copy all the source 
>>>>> files necessary into the right local directory such that the go compiler 
>>>>> can find them; ATM this is 
>>>>> /usr/share/gocode/golang.xenproject.org/xenlight
>>>> Nit:  This of course should have a `src/` between `gocode/` and 
>>>> `golang.xenproject.org/`.
>>>>
>>>> NB also that this naming scheme was designed so that at some point in the 
>>>> future, we could actually host the xenlight packages at the URL provided.
>>>>
>>>>  -George
>>>>
>>> This new mechanism of modules is described here:
>>> https://golang.org/cmd/go/#hdr-Modules__module_versions__and_more
>>>
>>> The module system is intended to supersede the GOPATH approach and
>>> provide a way to get versioned dependencies, as such
>>> it does not rely on GOPATH at all and doesn't use sources or compiled
>>> packages present in GOPATH elements such as /usr/share/gocode
>>> and systematically fetch (at the asked version) and compile a copy of
>>> the dependency as it might be a different version from the one
>>> in GOPATH.
>>>
>>> As far as I tried, I have been unable to build my module even with the
>>> library installed.
>>> I have to use xenbits.xen.org/git-http/xen.git/tools/golang/xenlight (or
>>> one of its mirror) in order to build the module using the new
>>> mechanism

This will break as soon as we have support in golang/xenlight for libxl
features not in the version of Xen you're using.

E.g., suppose you're on Xen 4.12.  Someone introduces a new feature in
Xen 4.13, and plumbs it all the way from Xen, through libxl, *and*
golang/xenlight.  Now when *you* do a build, it will fail, because your
version of golang will expect libxl features which your system doesn't have.

I had always planned on getting golang.xenproject.org set up such that
it could interact with the "normal" go get thing.  If you want to help
us figure out how to get that set up, that would be helpful.

What would be *really* ideal is if we didn't have to link golang against
one particular hypervisor.  Maybe we need to use plugins?
https://golang.org/pkg/plugin/

 -George

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