-
Notifications
You must be signed in to change notification settings - Fork 7
GSoC 18 Summary
RamyElkest edited this page Aug 14, 2018
·
7 revisions
In April 2018 I was accepted as part of the Google Summer of Code program to work with libvirt on generating nodejs bindings for the C libvirt API based on libvirt's exported API XML (see here and here for more details).
With Martin Kletzander and Erik Skultety as my mentors, I've worked over the following three months on this repository aiming for our goal.
Weekly updates (including what was done and links to PRs) can be found here. (thanks to a suggestion by mentors).
I've included it here for convenience
- Created a trello board
- Started playing around/looking into NaN vs N-API
- Deeper look into:
- node_api (C lib) vs node-addon-api (C++ lib)
- libvirt-python's client API
- node-libvirt's client API
- 94e6131: Added manual bindings for
virConnect,virDomainLookupByName,virDomainGetIDfollowing libvirt-python's API style
- Defined an initial list proposal of the minimal manual bindings needed before starting with the generator.
- Covers the creation of each libvirt "class" (apart from secret, stream, and event)
- Attempts to cover some non uniform cases
- Updated pull request for our initial manual bindings, getting us slightly closer to the target template.
- Created proof of concept for defining the js interface using the napi API
- Design Decisions: NodeJS Binding API writeup
- Created a PR to create generation infrastructure, this includes
- A generator script that (for now) just outputs the previous manual code to files
- A bunch of npm scripts to:
- check libvirt version / api xmls / etc.
- run the generate script
- install and test
- a makefile to wrap the npm scripts
- Created proof of concept for defining js interface using node-addon-api (wrapping c++ objects).
- My main aim was to highlight that we can arrive to something like this where with a bit of framework forwarding calls is a(n easily generatable) one liner
- However I still stand by our decision to expose the API as a JS API. I think we're now in a good position to fill out the JS vs. C(++) API design decision
- I tried to get in touch with the node-libvirt contributors in hope to schedule a few minutes to discuss any difficulties/hacks they had etc. however no response just yet.
- Repository (branch) cleanup to move things along
- Merged PR1 Initial_code into master
- Merged PR5 generator into master after resolving conflicts
- Closed PR2 and PR6 proof of concepts
- Created travis CI to run on PRs
- Opened PR for initial Override and manual infrastructure to enable overridding generated functions (although we don't have the generated stubs yet)
- Committed manual implementation of
virConnectCloseand partialvirConnectRegisterCloseCallback(but still requires some work before PR)..- (Started work on API parser, but nothing useful yet)
- Created Parser/Generator rough prototype
- We're able to generate virConnectOpen
- pending one small (expected) issue: generalising checking for error returned from libvirt (be it null pointer or eg. -1)
- Created partial virConnectRegisterCloseCallback implementation pending some clarification on usage.
- Refactoring generators
- Following functions are now generated using the parser and a whitelist with Generating most manual functions
virConnectOpenvirConnectClosevirDomainLookupByNamevirDomainGetIDvirDomainGetURI
- This week brings an important milestone -- End to End generation (js + C header + C impl + napi export)
- Example highlighted using
virDomainGetVcpusFlags- Adding e2e generation for primitive types adds support for generating wrappers and napi exports
- Following from last week's Adding e2e generation for primitive types we added support for most primitive virDomain functions (untested)
- Added npm script to clang-format generated files
- Added generation of wrapper objects
- https://repl.it/@relkest/libvirt-node-eventemitter communications sample for upcoming refactoring
- Major refactoring to allow:
- Adding file dependencies at runtime
- Adding ability to override default generators (and manual implementations)
- Adding support to generate library level functions (eg. libvirt.open, etc.)
- Adding support to generated enums at library level
- Started Architecture documentation
- Added sanitytest.js to track implemented function count
- We now generate all enums
- Added support for vir.ListAll. functions
- Whitelist all libvirt functions (failing functions are commented out with the error)
- Added README.md
- Migrated tests to mocha and added some for reference
- Published libvirt-node on npm!
- Created GSoC Summary for final submission.
The gsoc18 branch represents a frozen snapshot of the final deliverable for GSoC18.
On a high level what has been done:
- Some initial research to decide on the direction to move in
- A build system (Make integrated with npm) that checks libvirt dependencies, compiles, runs tests, etc.
- Continuous integration via travis-ci to validate builds / pull requests
- sanitytest.js to report the API coverage
- Framework in place to easily override default implementations with a handwritten one
- Sample tests for usage and sanity
- High level documentation on architecture and build process
- Generation of all enums at library level (similar to libvirt-python)
- Generation of all libvirt functions that use ~primitive types (eg.
int,const char *) or one of the generated types eg. (virInterface) - published npm module
Although this is a solid step in the right direction, there's still plenty to be done for this project.
- sanitytest.js currently reports ~65% of functions have been generated. We need more work to get this closer to 100%.
- Tested support for lxc and qemu APIs: The APIs are parsed and processed but not generated as the focus was on libvirt-api.
- Issues that have been raised need to be addressed.
- It would be good to get it battle-tested before hitting
v1.0.0through additional tests and additional users/contributors. - Some potentially beneficial future improvements like an async API and typescript interface definitions.