On 7/19/19 1:04 PM, George Dunlap wrote: > 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.dun...@citrix.com> >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>>> On Jul 19, 2019, at 8:34 AM, Nicolas Belouin >>>>>>> <nicolas.belo...@gandi.net> 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.belo...@gandi.net> >>>>>>>> Signed-off-by: George Dunlap <george.dun...@citrix.com> >>>>>>>> --- >>>>>>>> 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 know of that, and that can be overcome using modules as you can specify a branch version of the module you depends on (e.g you can set your dependency as being xxx/xenlight@stable-4.12). > > 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.
As far as I looked into vanity URLs, you can't serve a subdirectory of a repository directly, but you can trick the system using a go-proxy. To do that you need two things. First, you need https://golang.xenproject.org/xenlight?go-get=1 <https://example.org/pkg/foo?go-get=1> to point to a page containing a <meta name="go-import" content="golang.xenproject.org mod https://golang.xenproject.org/moduleproxy <https://code.org/moduleproxy>"> And have golang.xenproject.org/moduleproxy to follow the specifications of module proxies by proposing '.zip' files containing the different versions of the module. This part for sure can be scripted to do the hard work of dynamically packaging the versions from the git repository on demand. > > 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/ This is the Go equivalent of ldopen, I'm not fond of this approach in general, but something like this can indeed do the trick to keep from linking against libxl directly, it would need a split in two modules to be easily usable though. Nicolas _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
