On Fri, 2009-07-24 at 16:42 +0200, Daniel Veillard wrote:
On Wed, Jul 22, 2009 at 04:01:47PM -0300, Eduardo Otubo wrote:
Hello everyone,
This should be the official patch for the libvrt-0.7.0 release. Here I'll comment all the features already implemented and the roadmap we have ahead:
Features supported: * Connects to HMC/VIOS or IVM systems. * Life cycle commands (resume and shutdown). * dumpxml * 'list' and 'list --all'
What is being implemented: * better and centralized control for UUID * definexml * CPU management commands
Okidoc, I have pushed them to git, congrats !
Thank you very much! :)
Any comment are always welcome. [...] +static char * +phypExec(SSH_SESSION * session, char *cmd, int *exit_status, + virConnectPtr conn) [...] + char *lpar_name = + phypExec(ssh_session, cmd, (int *) exit_status, conn);
obviously those (int *) exit_status had to be changed to &exit_status I cleaned this up before the commit :-)
I also had to clean a few things because the merge conflicted with the ESX one from yesterday but nothing important.
However I have a serioud beef with the choice of libssh. That had been examined when this was started but I still think the issue should be revisited:
- ESX driver now depend on libcurl which depends on the concurrent library libssh2 - libssh seems in its infancy, right now the version in Fedora development is 0.2, upstream is 0.3.1 radical change of naming - the phyp driver fails to build against 0.2 version, as they changed API signatures :-( , it compile agaisnt 0.3.1 but it's not generally available. - the -devel rpm doesn't even export a .pc file to easilly test against a given version in configure - rebuilding the src.rpm from upstream results in a shared lib being installed in libssh3, and the header files being in libssh-devel, when one consider there is also libssh2 needed for the build this is getting very very confusing - I have a very hard time promoting the use of a library which does things like typedef struct string_struct STRING; typedef struct buffer_struct BUFFER; and typedef uint32_t u32; typedef uint16_t u16; steeping onto the global naming space and being garanteed to be a pain in the long run (or completely break its published API to fix it)
So right now I had to disable compilation of phys in the rpm because of those issues especially the API breakage leading to compilation failure if the wrong libssh-devel version was installed and the impossibility to test this easilly in the configure.in
I somehow remember you might be okay to switch to libssh2 if really needed, and considering the uglyness of libssh current state I guess the option should be at least seriously considered.
Daniel, As we talked in the IRC, I'll start working on the migration to libssh2. I'll post my feedbacks as soon as I have some compilable code to show :) []'s -- Eduardo Otubo Software Engineer Linux Technology Center IBM Systems & Technology Group Mobile: +55 19 8135 0885 otubo@linux.vnet.ibm.com