[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 1/5] libxl: Generate golang bindings in libxl Makefile


  • To: Nick Rosbrook <rosbrookn@xxxxxxxxx>
  • From: George Dunlap <George.Dunlap@xxxxxxxxxx>
  • Date: Mon, 8 Jun 2020 09:54:13 +0000
  • Accept-language: en-GB, en-US
  • Authentication-results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none
  • Cc: Nick Rosbrook <rosbrookn@xxxxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Ian Jackson <Ian.Jackson@xxxxxxxxxx>
  • Delivery-date: Mon, 08 Jun 2020 09:54:24 +0000
  • Ironport-sdr: uciO5fGTX5/SSRaOQx6k1Ix5gzIBEzqMApsUZKz8y9iEr8T6UhYnhg6+DiAU9IMdy7irlH3r9R P1AMDtUHe/hs/e0LtOu4c6aUm2RyHHiRAIUg/cOL7WBIrnAU2YMCb0Tgr+jJsXMIpWKV7ZDeR4 TJU+PC0Slo0fqxKSXqTM9ryu+0XGT3TjrNXjzX/xtwFY1x2yLUSPoQJC1cV+X7b6VtK2qnw7+N lrc+0NCN9qmeL5YgIgJ9UKE7B2iuTHbOdKNH8owvLoe8+PlsR6Uh+1V3GhU1ZGQ2OK93RDjBWa llE=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHWM6tS08XNp9FsPk2dfrAVrD4GiajIlOUAgAAecgCABblSgA==
  • Thread-topic: [PATCH v2 1/5] libxl: Generate golang bindings in libxl Makefile


> On Jun 4, 2020, at 7:29 PM, Nick Rosbrook <rosbrookn@xxxxxxxxx> wrote:
> 
>> The simplest short-term way to fix this would be to remove the `go fmt` call 
>> from `gengotypes.py`.  It’s actually relatively unusual for generated code 
>> to look pretty (or even be looked at).  We could also consider adding in 
>> some “manual” formatting in gengotypes.py, like indentation, so that it 
>> doesn’t look too terrible.
>> 
>> Nick, do you have time to work on a patch like that?
> 
> Yes, I have time to work on a quick patch for this. I'll see what it
> would take to add a bit of basic manual formatting, but of course the
> original purpose of using gofmt was to avoid re-creating formatting
> logic. I'll likely just remove the call to go fmt.
> 
> Out of curiosity, would it be totally out of the question to require
> having gofmt installed (not for 4.14, but in the future)? I ask because
> I haven't seen it discussed one way or the other.

I think I’d like to try to avoid it, unless / until we have a “core component” 
written in golang.  For one, if we added it as a core dependency, we’d need to 
be  backwards compatible to the oldest version of golang of distros on which we 
want to build; that would include  Debian oldstable, Ubuntu LTS, probably 
CentOS 7 at least, possibly CentOS 6, and so on.  If any of those didn’t have 
golang available, then we’d basically have to decide between dropping support 
for those distros, and making golang optional.

I don’t at the moment have a good feel for what other people in the community 
feel about this, but generally speaking being fanatically backwards compatible 
is an investment in the long-term ecosystem; keeping Xen *as a whole* building 
on older distros is an example of that.  (FWIW I don’t think we have an 
official rubric, but my starting point is that we should try to build on all 
still-supported major distros; that would include CentOS 6 until Q4 of 2020, if 
my quick Google search is correct.)

One advantage of making golang optional is that we don’t have to be quite so 
backwards compatible — up until we declare the feature “fully supported”, we 
can move the minimum required version forward at will if we want to rely on new 
features.

 -George

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.