[libvirt] remote_protocol.{c,h} ?
Hi, Is it really true that qemud/remote_protocol.{c,h} are created by rpcgen? If so, why dont we have them created at compile time? I still see them in the source code. I modified remote_protocol.x a bit, and when recompiling, remote_protocol.{c,h} are not reflected at all. So it is expected that developers must recompile with rpcgen themself?? Thanks, Jun
On Wed, Sep 3, 2008 at 1:00 PM, Jun Koi <junkoi2004@gmail.com> wrote:
Hi,
Is it really true that qemud/remote_protocol.{c,h} are created by rpcgen? If so, why dont we have them created at compile time? I still see them in the source code.
I modified remote_protocol.x a bit, and when recompiling, remote_protocol.{c,h} are not reflected at all. So it is expected that developers must recompile with rpcgen themself??
I looked again, and see that we can generate remote_protocol.c from rpcgen. Currently it seems remote_protocol.c is hacked a bit to remove some unused stack variables? Why do we need to do such a thing, while compiler can optimize that for us? So I guess it is better to have rpcgen does all the job, and leave everything as it is. We can rename remote_protocol_xdr.c to remote_protocol.c if you still insist that (but I see no good reason to do so). Thanks, Jun
On Wed, Sep 3, 2008 at 2:33 PM, Jun Koi <junkoi2004@gmail.com> wrote:
On Wed, Sep 3, 2008 at 1:00 PM, Jun Koi <junkoi2004@gmail.com> wrote:
Hi,
Is it really true that qemud/remote_protocol.{c,h} are created by rpcgen? If so, why dont we have them created at compile time? I still see them in the source code.
I modified remote_protocol.x a bit, and when recompiling, remote_protocol.{c,h} are not reflected at all. So it is expected that developers must recompile with rpcgen themself??
I looked again, and see that we can generate remote_protocol.c from rpcgen. Currently it seems remote_protocol.c is hacked a bit to remove some unused stack variables? Why do we need to do such a thing, while compiler can optimize that for us?
So I guess it is better to have rpcgen does all the job, and leave everything as it is. We can rename remote_protocol_xdr.c to remote_protocol.c if you still insist that (but I see no good reason to do so).
Ah, I found the fixup script, and now it makes more sense to me ;-) Thanks, Jun
On Wed, Sep 03, 2008 at 02:33:09PM +0900, Jun Koi wrote:
I looked again, and see that we can generate remote_protocol.c from rpcgen. Currently it seems remote_protocol.c is hacked a bit to remove some unused stack variables? Why do we need to do such a thing, while compiler can optimize that for us?
It's just to remove some compiler warnings, and possibly some real problems. The code generated by glibc rpcgen contains type punning issues. http://en.wikipedia.org/wiki/Type_punning Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top
On Wed, Sep 03, 2008 at 01:00:52PM +0900, Jun Koi wrote:
Is it really true that qemud/remote_protocol.{c,h} are created by rpcgen? If so, why dont we have them created at compile time? I still see them in the source code.
The reason is that only Linux glibc rpcgen can generate them correctly. rpcgen on other systems usually lacks some feature or other, commonly 64 bit types.
I modified remote_protocol.x a bit, and when recompiling, remote_protocol.{c,h} are not reflected at all. So it is expected that developers must recompile with rpcgen themself??
No, that should rebuild. Make sure you're using the CVS version of libvirt though. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 64 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
On Wed, Sep 3, 2008 at 8:41 PM, Richard W.M. Jones <rjones@redhat.com> wrote:
On Wed, Sep 03, 2008 at 01:00:52PM +0900, Jun Koi wrote:
Is it really true that qemud/remote_protocol.{c,h} are created by rpcgen? If so, why dont we have them created at compile time? I still see them in the source code.
The reason is that only Linux glibc rpcgen can generate them correctly. rpcgen on other systems usually lacks some feature or other, commonly 64 bit types.
I modified remote_protocol.x a bit, and when recompiling, remote_protocol.{c,h} are not reflected at all. So it is expected that developers must recompile with rpcgen themself??
No, that should rebuild. Make sure you're using the CVS version of libvirt though.
I patched version 0.4.4 and it doesnt automatically rebuild remote_protocol.c for me. So it is fixed in CVS already? Great! Thanks, Jun
On Fri, Sep 05, 2008 at 12:40:13PM +0900, Jun Koi wrote:
On Wed, Sep 3, 2008 at 8:41 PM, Richard W.M. Jones <rjones@redhat.com> wrote:
On Wed, Sep 03, 2008 at 01:00:52PM +0900, Jun Koi wrote:
Is it really true that qemud/remote_protocol.{c,h} are created by rpcgen? If so, why dont we have them created at compile time? I still see them in the source code.
The reason is that only Linux glibc rpcgen can generate them correctly. rpcgen on other systems usually lacks some feature or other, commonly 64 bit types.
I modified remote_protocol.x a bit, and when recompiling, remote_protocol.{c,h} are not reflected at all. So it is expected that developers must recompile with rpcgen themself??
No, that should rebuild. Make sure you're using the CVS version of libvirt though.
I patched version 0.4.4 and it doesnt automatically rebuild remote_protocol.c for me. So it is fixed in CVS already? Great!
Jim Meyering fixed this. I'm not sure if that was before or after 0.4.4 was released, but CVS seems to be OK for me. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 67 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
participants (2)
-
Jun Koi -
Richard W.M. Jones