[libvirt] [PATCH] Power Hypervisor support

Eduardo Otubo otubo at linux.vnet.ibm.com
Fri Jul 24 22:56:40 UTC 2009


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 at linux.vnet.ibm.com




More information about the libvir-list mailing list