Re: libvirt-devaddr: a new library for device address assignment
On 4/30/20 4:14 PM, Laine Stump wrote:
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!
[...]
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?
It would be of great help if we can get "inspiration" from another project to
get the initial CI/unit test
skeleton.
(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?)
I'd rather put it under a personal gitlab tree first. Putting it inside Libvirt
umbrella might generate
unrealistic expectations for something that's still on its infancy.
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).
My initial plan is to get the logic/APIs design from Libvirt, rename them in a Gopher
fashion, re-code
it with Go and call it a day :)
In all seriousness, we have some room to do "not so good" APIs and change them
if necessary since it's
a fresh project. In this stage we can start with simplified versions of the use cases
danpb described
in the first email of the thread and play by ear.
Thanks,
DHB