Sorry, I forgot to reply to your follow up question on the users list. 2011/4/6 James Barkley <james.barkley@xxxxxxxxx>: > Greetings: > I've added code to the ESX driver to support some basic network > functionality. I'm pretty new to this list, so please tell me how to proceed > with code review and patch submission (yes I've read the contributor > guidelines on the wiki). It seems like people are emailing a patch file for > every file they've changed, each in separate emails with [1 of N] in the > subject, is that right? Or is it better to paste in code, get some feedback, > and eventually attach the patch to the bug tracker item? The normal approach is to have one commit/patch per logical self-contained change. After each commit/patch the codebase has to be in a compilable stage. For example you cannot add the code using the generated SOAP bindings, before you actually added them to the esx_vi_generator.input file. The [1 of N] style patch series are typically used for large changes that are split in several logical, self-contained parts. Splitting like this simplifies reviewing and later on figuring out bugs using git bisect. You typically don't split on a per file basis. In your case I'd suggest to create a single commit/patch for your addition, as it is one logical piece of work. You _could_ (but I don't recommend to) split it in multiple patches. For example one for the esx_vi_generator.input addition, one for the VI helper function additions and one for the actual driver functions, but I'd consider this to be too fine grained. > I've updated the code for the ESX driver to be able to handle the following > functions : > - virNetworkLookupByName > - virConnectNumOfDefinedNetworks > - virConnectNumOfNetworks > - virConnectListNetworks Is this sufficient to make virsh net-list work? > I basically mapped the VMware Managed Object Reference for networks into a > few data structures and added the following functions to the internal driver You mean the managed object called Network? They _seem_ to be the natural fit. But I'm not sure if that's the correct approach, as you cannot directly create/destroy such objects and they are bound in some way to the port groups on a virtual switch. Also I'm not sure about the exact semantics of networks and port groups. That's what I meant as I said about the mapping between libvirt and VMware. We need to be sure to use the right approach from the start to avoid making breaking changes across releases later on. > API: > - esxNumOfNetworks > - esxListNetworks > - esxNumOfDefinedNetworks I assume you made esxNumOfDefinedNetworks return 0 to get virsh net-list working as there network in the VMware context are always active. > - esxNetworkLookupByName > - esxVI_LookupNetworkList > - esxVI_LookupNetworkByName > These functions were modeled after existing functions from the domain and > storage libraries. The following files were touched: > - esx_network_driver.c > - esx_vi.c > - esx_vi.h > - esx_vi_generator.input Apart from the question whether the Network managed object is the correct match, the next step is to send your patch to this list to get a review. The recommended way for sending patches is git send-email. Matthias -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list