On 7/19/19 2:19 PM, Nicolas Belouin wrote: > > > 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).
That's not terrible I guess. >> 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. Yes, that's sort of what I had in mind -- although it might be better to statically update the content with a crontab or something, rather than regenerating it from scratch every connection. >> 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. It's certainly a lot of work, but it seems a lot nicer than having to recompile your application every time you upgrade your hypervisor. :-) But obviously all that requires work and testing, which requires someone who has enough time to make it happen. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
