libvirt-devaddr: a new library for device address assignment

[Laine Stump]

On 4/30/20 2:20 PM, Daniel Henrique Barboza wrote:
>
>
> On 3/19/20 4:00 PM, Laine Stump wrote:
>> TL;DR - I'm not as anti-XML as the proposal seems to be, but also not 
>> pro-XML. I also (after thinking about it) understand the advantage of 
>> putting this in a separate library. So yeah, let's go it!
>
> [...]
>
>> Anyway, in the end I think my opinion is we should push ahead and 
>> think about consequences of the specifics later, after some 
>> experimenting. I'd love to help if there's a place for it. I'm just 
>> not sure where/how I could contribute, especially since I have only 
>> about 4 hours worth of golang knowledge :-) (certainly not against 
>> getting more though!)
>>
>>
>
>
> I'll start writing some code here and there for this initiative. Does
> anyone already started doing something? Otherwise I'll push code in
> github/gitlab when I have stuff to show.


Since I've been involved with libvirt's PCI address assignment code for 
quite a long time (and so there's a lot of knowledge about it embedded 
in my brain) I *should be* starting to do something with 
libvirt-devaddr, although I've been deliquent in asking danpb for more 
specific direction - as I said before this is a completely new medium 
for me, so I don't really know where to start.


Based on your enthusiasm, I'm guessing you have more experience than me 
with using go and various go libraries, is that right? If so that could 
be very helpful in getting it off the ground.


Here are two things that would help enable me to make useful contributions:


1) a basic "source tree for a go library" setup in a libvirt-subproject 
on gitlab (since gitlab is the official location of libvirt projects 
now), including basic commit and CI hooks/test cases. I'm guessing we 
could borrow/steal a lot from what was done by the people who 
participated in "virt-blocks" last fall. Andrea - any advice/suggestions 
to give here?


(A side question - should we put it under the libvirt umbrella on gitlab 
right away? Or play around in personal trees at first and then later 
fork it into an official libvirt project?)


2) a more concrete idea of what the API should look like. This is always 
the toughest part for me, since it is what the rest of the world sees, 
so it needs to be intelligible and capable of expansion, and I have a 
long history of making questionable choices that come back to haunt me 
(and everybody else! :-P). Since danpb has made good decisions in this 
area in the past (and since the original proposal is his), I'm 
thinking/hoping he can help provide direction to minimize mis-steps (on 
the other hand, I know he's really busy, so maybe he was just hoping 
that someone else would grab up his proposal and run with it).


Once those things are agreed upon and mostly in place, I think it will 
be more practical for multiple people to contribute, and in particular I 
will be able to put my memories of the idiosyncracies of libvirt and its 
PCI and other address allocation to better use (and hopefully I'll 
become more familiar with go in the process).



> My understanding from the discussions is that the API is going to supply
> JSON responses instead of domxml (domXML might be supplied as an option,
> but it wouldn't be the default format used). Is that correct?


I don't think there was any hard specification of the output format, 
just that it doesn't need to be married to XML. I've tended to view the 
current love affair with JSON as similar to 200x's love affair with XML, 
so I don't have any assumption that it's the best choice, but if there's 
nothing better, then  I guess why not?