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@xxxxxxxxxxxxxxxxxx -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list