[libvirt] RFC: Rename / move / delete files in GIT
With the 0.7.1 relesae out of the way I'd like to suggest that we take this time to move around some files in GIT to correct some long standing wierd/bad naming decisions :-) The qemud/ directory is better named 'daemon', and some of the things in there should really have been in the src/ directory. So... * qemud/ -> daemon/ * qemud/qemud.{h,c} daemon/main.{h,c} * qemud/default-network.xml -> src/network/default.xml * qemud/libvirtd_qemu.aug src/qemu/qemu.aug * qemud/test_libvirtd_qemu.aug src/qemu/test_qemu.aug * qemud/remote_protocol.x -> src/remote/remote_protocol.x In the src/ directory we should move the rest of the drivers into their own sub-directories. Basically want one sub directory for each of the 'mod_LTLIBRARIES' declared in the src/Makefile.am. This will ensure we keep separate build dependancies, not accidentally including files that we shouldn't. * src/qemu_*.{c,h} -> src/qemu/ * src/xen_unified.{c,h} -> src/xen/xen_driver.{c,h} * src/xend_*, src/xm_* src/xen_* -> src/xen/ * src/test.{c,h} -> src/test/test_driver.{c,h} * src/storage*.{c,h} -> src/storage/ * src/security*.{c,h} -> src/security/ * src/remote_internal.{c,h} -> src/remote/remote_driver.{c,h} * src/interface_driver.c -> src/interface/netcf_driver.c * src/network_driver.c -> src/network/network_driver.c * src/lxc_* -> src/lxc/ * src/openvz_* -> src/openvz/ * src/node_device* -> src/nodedev/ That would just leave all the shared source files in src/. We could leave them there, or create a src/util/ directory for that stuff. Move virsh into the tools directory * src/virsh.c -> tools/virsh.c * docs/virsh.pod -> tools/virsh.pod * virsh.1: delete from GIT Sanitise naming in python/ directory, to make it clear which are the manually overriden methods. * python/libvir.c -> python/override-api.c * python/libvir.py -> python/override-api.py * python/libvirt-python-api.xml python/override-api.xml * python/libvirt_wrap.h -> python/types.h * python/virConnect.py -> python/override-virConnect.py Cleanup the docs/ directory * docs/*.html.in -> docs/website/ * docs/*.html: delete from GIT * docs/devhelp: delete from GIT * docs/html: delete from GIT * docs/libvirt-{api,refs}.xml: delete from GIT * docs/examples/ -> examples/ * docs/test*xml -> examples/xml/test/ * docs/storage -> examples/xml/storage/ Remove include/libvirt/libvirt.h from GIT For there places where I list 'delete from GIT', we would ensure that when you run 'make dist' the files are still included in the tar.gz NB, we would also update the cron job that deploys the website on libvirt.org soo that it runs 'make' in the docs/website directory to generate the .html files. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
* qemud/ -> daemon/ * qemud/qemud.{h,c} daemon/main.{h,c} * qemud/default-network.xml -> src/network/default.xml * qemud/libvirtd_qemu.aug src/qemu/qemu.aug * qemud/test_libvirtd_qemu.aug src/qemu/test_qemu.aug * qemud/remote_protocol.x -> src/remote/remote_protocol.x
100% agreed (I would have chosen libvirtd/ and libvirtd/libvirtd.{h,c} but that's my taste).
In the src/ directory we should move the rest of the drivers into their own sub-directories. Basically want one sub directory for each of the 'mod_LTLIBRARIES' declared in the src/Makefile.am.
This is a good idea. Do you plan to make separate makefiles too? Also, it would be nice to rename moddir to modexecdir; the name is awful, but it ensures that Automake's "make install-exec" installs them rather than "make install-data". From the manual: Variables using the standard directory prefixes `data', `info', `man', `include', `oldinclude', `pkgdata', or `pkginclude' are installed by `install-data'. Variables using the standard directory prefixes `bin', `sbin', `libexec', `sysconf', `localstate', `lib', or `pkglib' are installed by `install-exec'. For instance, `data_DATA' files are installed by `install-data', while `bin_PROGRAMS' files are installed by `install-exec'. Any variable using a user-defined directory prefix with `exec' in the name (e.g., `myexecbin_PROGRAMS') is installed by `install-exec'. All other user-defined prefixes are installed by `install-data'.
Move virsh into the tools directory
* src/virsh.c -> tools/virsh.c * docs/virsh.pod -> tools/virsh.pod * virsh.1: delete from GIT
Yes!
* docs/examples/ -> examples/ * docs/test*xml -> examples/xml/test/ * docs/storage -> examples/xml/storage/
Also very appreciated.
For there places where I list 'delete from GIT', we would ensure that when you run 'make dist' the files are still included in the tar.gz
You can use distcheck-hook for that. Paolo
On Tue, Sep 15, 2009 at 02:07:58PM +0200, Paolo Bonzini wrote:
For there places where I list 'delete from GIT', we would ensure that when you run 'make dist' the files are still included in the tar.gz
You can use distcheck-hook for that.
please use dist-hook, not distcheck-hook, as it's really make dist which is used to generate the tarball, thanks Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On Tue, Sep 15, 2009 at 02:07:58PM +0200, Paolo Bonzini wrote:
* qemud/ -> daemon/ * qemud/qemud.{h,c} daemon/main.{h,c} * qemud/default-network.xml -> src/network/default.xml * qemud/libvirtd_qemu.aug src/qemu/qemu.aug * qemud/test_libvirtd_qemu.aug src/qemu/test_qemu.aug * qemud/remote_protocol.x -> src/remote/remote_protocol.x
100% agreed (I would have chosen libvirtd/ and libvirtd/libvirtd.{h,c} but that's my taste).
In the src/ directory we should move the rest of the drivers into their own sub-directories. Basically want one sub directory for each of the 'mod_LTLIBRARIES' declared in the src/Makefile.am.
This is a good idea. Do you plan to make separate makefiles too?
I'm undecided, but it is probably best to just keep a single Makefile.am in src/ because that will let make parallelize the build better which is important when I build with 'make -j 16' :-) In fact in many ways it'd be nice to have a 100% non-recursive make so we can express the true build dependancies for everything instead of having to rely on SUBDIR build ordering for things like python/ depending on apibuild.py under docs/ But one step at a time.
Also, it would be nice to rename moddir to modexecdir; the name is awful, but it ensures that Automake's "make install-exec" installs them rather than "make install-data".
I don't particularly care about the name choice, so fine to rename it to modexecdir instead. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On Tue, Sep 15, 2009 at 11:38:19AM +0100, Daniel P. Berrange wrote:
With the 0.7.1 relesae out of the way I'd like to suggest that we take this time to move around some files in GIT to correct some long standing wierd/bad naming decisions :-)
The qemud/ directory is better named 'daemon', and some of the things in there should really have been in the src/ directory. So...
* qemud/ -> daemon/ * qemud/qemud.{h,c} daemon/main.{h,c} * qemud/default-network.xml -> src/network/default.xml * qemud/libvirtd_qemu.aug src/qemu/qemu.aug * qemud/test_libvirtd_qemu.aug src/qemu/test_qemu.aug * qemud/remote_protocol.x -> src/remote/remote_protocol.x
ACK, though daemon/main.{h,c} could be libvirtd.{h,c}, not a big deal though
In the src/ directory we should move the rest of the drivers into their own sub-directories. Basically want one sub directory for each of the 'mod_LTLIBRARIES' declared in the src/Makefile.am. This will ensure we
ACK
keep separate build dependancies, not accidentally including files that we shouldn't.
* src/qemu_*.{c,h} -> src/qemu/ * src/xen_unified.{c,h} -> src/xen/xen_driver.{c,h} * src/xend_*, src/xm_* src/xen_* -> src/xen/ * src/test.{c,h} -> src/test/test_driver.{c,h} * src/storage*.{c,h} -> src/storage/ * src/security*.{c,h} -> src/security/ * src/remote_internal.{c,h} -> src/remote/remote_driver.{c,h} * src/interface_driver.c -> src/interface/netcf_driver.c * src/network_driver.c -> src/network/network_driver.c * src/lxc_* -> src/lxc/ * src/openvz_* -> src/openvz/ * src/node_device* -> src/nodedev/
yup sounds fine to me
That would just leave all the shared source files in src/. We could leave them there, or create a src/util/ directory for that stuff.
I'm fine keeping in the main dir for the moment.
Move virsh into the tools directory
* src/virsh.c -> tools/virsh.c * docs/virsh.pod -> tools/virsh.pod
Could be left in docs, both places are IMHO adequate
* virsh.1: delete from GIT
Okay but we need to make sure it's generated for EXTRA_DIST / dist
Sanitise naming in python/ directory, to make it clear which are the manually overriden methods.
* python/libvir.c -> python/override-api.c * python/libvir.py -> python/override-api.py * python/libvirt-python-api.xml python/override-api.xml * python/virConnect.py -> python/override-virConnect.py
okay
* python/libvirt_wrap.h -> python/types.h
the types are wrappers, the problem is that "types.h" is so generic that it's more likely to raise portability problems, I would avoid that change
Cleanup the docs/ directory
* docs/*.html.in -> docs/website/
Hum ... I'm not that fond of that, sure it's used for the website but it's still the main documentation, and I like to have the full docs tree checkout being the website. If you search the .xml they are on the web too, at a predictable place.
* docs/*.html: delete from GIT * docs/devhelp: delete from GIT * docs/html: delete from GIT
It's not that much of churn, I don't remember any time where this generated a problem, and this makes the EXTRA_DIST / dist more complex. I'm not convinced it will really heklp that much, nor save much bandwidth either.
* docs/libvirt-{api,refs}.xml: delete from GIT
Disagree, I want those to be in git to see diff, and also to make sure one can rebuild the python bindings on a platfor where the generation may fail.
* docs/examples/ -> examples/ * docs/test*xml -> examples/xml/test/ * docs/storage -> examples/xml/storage/
okay
Remove include/libvirt/libvirt.h from GIT
Since the generation of that file is really a direct output of running configure, okay
For there places where I list 'delete from GIT', we would ensure that when you run 'make dist' the files are still included in the tar.gz
Yes but still I would prefer to keep some of it in git.
NB, we would also update the cron job that deploys the website on libvirt.org soo that it runs 'make' in the docs/website directory to generate the .html files.
I'm not fond of a subdirectory for the web site. I really think everything out of doc should be reachable with a trivial http:// url Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On Tue, Sep 15, 2009 at 03:36:13PM +0200, Daniel Veillard wrote:
On Tue, Sep 15, 2009 at 11:38:19AM +0100, Daniel P. Berrange wrote:
With the 0.7.1 relesae out of the way I'd like to suggest that we take this time to move around some files in GIT to correct some long standing wierd/bad naming decisions :-)
The qemud/ directory is better named 'daemon', and some of the things in there should really have been in the src/ directory. So...
* qemud/ -> daemon/ * qemud/qemud.{h,c} daemon/main.{h,c} * qemud/default-network.xml -> src/network/default.xml * qemud/libvirtd_qemu.aug src/qemu/qemu.aug * qemud/test_libvirtd_qemu.aug src/qemu/test_qemu.aug * qemud/remote_protocol.x -> src/remote/remote_protocol.x
ACK, though daemon/main.{h,c} could be libvirtd.{h,c}, not a big deal though
Ok, paulo suggested that too, so i'll go for that instead.
That would just leave all the shared source files in src/. We could leave them there, or create a src/util/ directory for that stuff.
I'm fine keeping in the main dir for the moment.
Move virsh into the tools directory
* src/virsh.c -> tools/virsh.c * docs/virsh.pod -> tools/virsh.pod
Could be left in docs, both places are IMHO adequate
I think its important to have the POD docs in the same place as the source file, mostly so its obvious that people changing the virsh.c will see there's a man page that needs changing too.
* python/libvirt_wrap.h -> python/types.h
the types are wrappers, the problem is that "types.h" is so generic that it's more likely to raise portability problems, I would avoid that change
Ok, I'll think of a name that's less likely to clash - just wanted the .c and .h to have the same base name here.
Cleanup the docs/ directory
* docs/*.html.in -> docs/website/
Hum ... I'm not that fond of that, sure it's used for the website but it's still the main documentation, and I like to have the full docs tree checkout being the website. If you search the .xml they are on the web too, at a predictable place.
* docs/*.html: delete from GIT * docs/devhelp: delete from GIT * docs/html: delete from GIT
It's not that much of churn, I don't remember any time where this generated a problem, and this makes the EXTRA_DIST / dist more complex. I'm not convinced it will really heklp that much, nor save much bandwidth either.
Mostly just that it is rather a pain to have these files creating huge changesets when doing API work. Or changing sitemap.html.in for example results in a giant changeset affecting every html file which is obscuring the real change when doing reviews.
* docs/libvirt-{api,refs}.xml: delete from GIT
Disagree, I want those to be in git to see diff, and also to make sure one can rebuild the python bindings on a platfor where the generation may fail.
The API generator should really ever fail on other OS, since it is pure python + libxml2 both of which are pretty reliable & portable.
For there places where I list 'delete from GIT', we would ensure that when you run 'make dist' the files are still included in the tar.gz
Yes but still I would prefer to keep some of it in git.
NB, we would also update the cron job that deploys the website on libvirt.org soo that it runs 'make' in the docs/website directory to generate the .html files.
I'm not fond of a subdirectory for the web site. I really think everything out of doc should be reachable with a trivial http:// url
The goal was to try and make it clear what's part of the website and what's not - eg some bits under docs/ are not part of the website. I will try a different approach though, leave the website where it is and see if any of the other bits are better elsewhere. eg pki_check.sh might be better as tools/virt-pki-check FYI, i'll have a go at making these changes and make them visible as a branch on my gitorious.org repository so other people can see what it all looks like Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On Tue, Sep 15, 2009 at 03:18:41PM +0100, Daniel P. Berrange wrote:
On Tue, Sep 15, 2009 at 03:36:13PM +0200, Daniel Veillard wrote:
On Tue, Sep 15, 2009 at 11:38:19AM +0100, Daniel P. Berrange wrote:
With the 0.7.1 relesae out of the way I'd like to suggest that we take this time to move around some files in GIT to correct some long standing wierd/bad naming decisions :-)
The qemud/ directory is better named 'daemon', and some of the things in there should really have been in the src/ directory. So...
* qemud/ -> daemon/ * qemud/qemud.{h,c} daemon/main.{h,c} * qemud/default-network.xml -> src/network/default.xml * qemud/libvirtd_qemu.aug src/qemu/qemu.aug * qemud/test_libvirtd_qemu.aug src/qemu/test_qemu.aug * qemud/remote_protocol.x -> src/remote/remote_protocol.x
ACK, though daemon/main.{h,c} could be libvirtd.{h,c}, not a big deal though
Ok, paulo suggested that too, so i'll go for that instead.
thanks !
That would just leave all the shared source files in src/. We could leave them there, or create a src/util/ directory for that stuff.
I'm fine keeping in the main dir for the moment.
Move virsh into the tools directory
* src/virsh.c -> tools/virsh.c * docs/virsh.pod -> tools/virsh.pod
Could be left in docs, both places are IMHO adequate
I think its important to have the POD docs in the same place as the source file, mostly so its obvious that people changing the virsh.c will see there's a man page that needs changing too.
Okay, good point, didn't think about this
* python/libvirt_wrap.h -> python/types.h
the types are wrappers, the problem is that "types.h" is so generic that it's more likely to raise portability problems, I would avoid that change
Ok, I'll think of a name that's less likely to clash - just wanted the .c and .h to have the same base name here.
okay
Cleanup the docs/ directory
* docs/*.html.in -> docs/website/
Hum ... I'm not that fond of that, sure it's used for the website but it's still the main documentation, and I like to have the full docs tree checkout being the website. If you search the .xml they are on the web too, at a predictable place.
* docs/*.html: delete from GIT * docs/devhelp: delete from GIT * docs/html: delete from GIT
It's not that much of churn, I don't remember any time where this generated a problem, and this makes the EXTRA_DIST / dist more complex. I'm not convinced it will really heklp that much, nor save much bandwidth either.
Mostly just that it is rather a pain to have these files creating huge changesets when doing API work. Or changing sitemap.html.in for example results in a giant changeset affecting every html file which is obscuring the real change when doing reviews.
It's true that adding a single entry update them all
* docs/libvirt-{api,refs}.xml: delete from GIT
Disagree, I want those to be in git to see diff, and also to make sure one can rebuild the python bindings on a platfor where the generation may fail.
The API generator should really ever fail on other OS, since it is pure python + libxml2 both of which are pretty reliable & portable.
Failure to build is only a small part of my attachment to keeping it in git, it's the fact that change to libvirt-api.xml are really indicative of interface changes, and I really like them recorded and be able to spot changes immediately on git diff/status I don't really care about -refs that's really glue, but -api is a primary resource for me, even if it's generated in some ways (not systematic).
For there places where I list 'delete from GIT', we would ensure that when you run 'make dist' the files are still included in the tar.gz
Yes but still I would prefer to keep some of it in git.
NB, we would also update the cron job that deploys the website on libvirt.org soo that it runs 'make' in the docs/website directory to generate the .html files.
I'm not fond of a subdirectory for the web site. I really think everything out of doc should be reachable with a trivial http:// url
The goal was to try and make it clear what's part of the website and what's not - eg some bits under docs/ are not part of the website. I will try a different approach though, leave the website where it is and see if any of the other bits are better elsewhere. eg pki_check.sh might be better as tools/virt-pki-check
Okay, what about having the .html.in in a website subtree but the generated output in docs/ so that docs/ subtree is what is available via HTTP ?
FYI, i'll have a go at making these changes and make them visible as a branch on my gitorious.org repository so other people can see what it all looks like
okay, Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On Tue, 2009-09-15 at 11:38 +0100, Daniel P. Berrange wrote:
With the 0.7.1 relesae out of the way I'd like to suggest that we take this time to move around some files in GIT to correct some long standing wierd/bad naming decisions :-)
The qemud/ directory is better named 'daemon', and some of the things in there should really have been in the src/ directory. So...
* qemud/ -> daemon/ * qemud/qemud.{h,c} daemon/main.{h,c} * qemud/default-network.xml -> src/network/default.xml * qemud/libvirtd_qemu.aug src/qemu/qemu.aug * qemud/test_libvirtd_qemu.aug src/qemu/test_qemu.aug * qemud/remote_protocol.x -> src/remote/remote_protocol.x
In the src/ directory we should move the rest of the drivers into their own sub-directories. Basically want one sub directory for each of the 'mod_LTLIBRARIES' declared in the src/Makefile.am. This will ensure we keep separate build dependancies, not accidentally including files that we shouldn't.
* src/qemu_*.{c,h} -> src/qemu/ * src/xen_unified.{c,h} -> src/xen/xen_driver.{c,h} * src/xend_*, src/xm_* src/xen_* -> src/xen/ * src/test.{c,h} -> src/test/test_driver.{c,h} * src/storage*.{c,h} -> src/storage/ * src/security*.{c,h} -> src/security/ * src/remote_internal.{c,h} -> src/remote/remote_driver.{c,h} * src/interface_driver.c -> src/interface/netcf_driver.c * src/network_driver.c -> src/network/network_driver.c
Why did you go with src/network/bridge_driver.[ch] for this ? It doesn't seem right to me - we refer to it as the network driver, all the code is networkFooBar(), it's in the network/ directory, ... Cheers, Mark.
On Wed, Sep 23, 2009 at 03:25:28PM +0100, Mark McLoughlin wrote:
On Tue, 2009-09-15 at 11:38 +0100, Daniel P. Berrange wrote:
With the 0.7.1 relesae out of the way I'd like to suggest that we take this time to move around some files in GIT to correct some long standing wierd/bad naming decisions :-)
The qemud/ directory is better named 'daemon', and some of the things in there should really have been in the src/ directory. So...
* qemud/ -> daemon/ * qemud/qemud.{h,c} daemon/main.{h,c} * qemud/default-network.xml -> src/network/default.xml * qemud/libvirtd_qemu.aug src/qemu/qemu.aug * qemud/test_libvirtd_qemu.aug src/qemu/test_qemu.aug * qemud/remote_protocol.x -> src/remote/remote_protocol.x
In the src/ directory we should move the rest of the drivers into their own sub-directories. Basically want one sub directory for each of the 'mod_LTLIBRARIES' declared in the src/Makefile.am. This will ensure we keep separate build dependancies, not accidentally including files that we shouldn't.
* src/qemu_*.{c,h} -> src/qemu/ * src/xen_unified.{c,h} -> src/xen/xen_driver.{c,h} * src/xend_*, src/xm_* src/xen_* -> src/xen/ * src/test.{c,h} -> src/test/test_driver.{c,h} * src/storage*.{c,h} -> src/storage/ * src/security*.{c,h} -> src/security/ * src/remote_internal.{c,h} -> src/remote/remote_driver.{c,h} * src/interface_driver.c -> src/interface/netcf_driver.c * src/network_driver.c -> src/network/network_driver.c
Why did you go with src/network/bridge_driver.[ch] for this ?
It is an implementation of the network driver using a bridge, but will not be the only impl forever. I'm planning ahead for the time when we add a 2nd implementation of the network driver, that is based on using NetworkManager to manage this functionality. This is what will finally enable qemu:///session to become a viable option for desktop virt since we won't need to have root privileges for messing around with bridges.
It doesn't seem right to me - we refer to it as the network driver, all the code is networkFooBar(), it's in the network/ directory, ...
Ideally we'd rename the methods, but I didn't think that would be worth the churn Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
participants (4)
-
Daniel P. Berrange -
Daniel Veillard -
Mark McLoughlin -
Paolo Bonzini