[libvirt] [PATCH] Allow storage FS backend to be disabled
# HG changeset patch # User john.levon@sun.com # Date 1229369745 28800 # Node ID 56d77e29bf90057791feebfa47506fc0933cd690 # Parent ce24d41d372948cd5440cf17bdb58ce33faffa84 Allow storage FS backend to be disabled It's Linux-specific, and it should be possible to disable it Signed-off-by: John Levon <john.levon@sun.com> diff --git a/src/Makefile.am b/src/Makefile.am --- a/src/Makefile.am +++ b/src/Makefile.am @@ -326,6 +326,9 @@ libvirt_driver_storage_la_LDFLAGS = -mod libvirt_driver_storage_la_LDFLAGS = -module -avoid-version endif libvirt_driver_storage_la_SOURCES += $(STORAGE_DRIVER_SOURCES) +endif + +if WITH_STORAGE_FS libvirt_driver_storage_la_SOURCES += $(STORAGE_DRIVER_FS_SOURCES) endif
On Mon, Dec 15, 2008 at 11:59:46AM -0800, john.levon@sun.com wrote:
# HG changeset patch # User john.levon@sun.com # Date 1229369745 28800 # Node ID 56d77e29bf90057791feebfa47506fc0933cd690 # Parent ce24d41d372948cd5440cf17bdb58ce33faffa84 Allow storage FS backend to be disabled
It's Linux-specific, and it should be possible to disable it
Yes & no. The storage_backend_fs.c file is actually 3 backends all in one file. - A directory based pool - A local filesystem based pool - A network filesystem based pool The directory based pool only uses trivial POSIX apis like open/read/write/close/stat and is intended to be the one impl that is guarenteed available on all operating systems. Thus we delibrately don't disable the whole compilation of this file in the Makefile.am The latter two pool definitely have linux-specific in them today, but in theory they could be ported. The WITH_STORAGE_FS conditional is supposed to be disabling the non-portable Linux code in the storage_backend_fs.c file, while leaving the portable directory based pool enabled. Its always possible we've introduced non-portability / bugs that need fixing. What compile errors do you get from the storage_backend_fs.c on Solaris when you run configure --without-storage-fs ? 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 Mon, Dec 15, 2008 at 09:51:18PM +0000, Daniel P. Berrange wrote:
It's Linux-specific, and it should be possible to disable it
Yes & no. The storage_backend_fs.c file is actually 3 backends all in one file.
- A directory based pool - A local filesystem based pool - A network filesystem based pool
The directory based pool only uses trivial POSIX apis like open/read/write/close/stat and is intended to be the one impl that is guarenteed available on all operating systems. Thus we delibrately don't disable the whole compilation of this file in the Makefile.am
Would be simpler to split out into separate files? This threw me.
What compile errors do you get from the storage_backend_fs.c on Solaris when you run configure --without-storage-fs ?
"/export/build/johnlev/xvm/xvm-vi/libvirt.hg/src/storage_backend_fs.c", line 34: error: cannot find include file: <endian.h> "/export/build/johnlev/xvm/xvm-vi/libvirt.hg/src/storage_backend_fs.c", line 35: error: cannot find include file: <byteswap.h> "/export/build/johnlev/xvm/xvm-vi/libvirt.hg/src/storage_backend_fs.c", line 36: error: cannot find include file: <mntent.h> "/export/build/johnlev/xvm/xvm-vi/libvirt.hg/src/storage_backend_fs.c", line 81: error: undefined symbol: __BIG_ENDIAN So line 36 needs moving within the #ifdef, and we need a general replacement for the endian stuff. I'm not sure what you're using from byteswap.h, but we can just define __*_ENDIAN if they're not, I think? regards john
On Mon, Dec 15, 2008 at 10:02:45PM +0000, John Levon wrote:
On Mon, Dec 15, 2008 at 09:51:18PM +0000, Daniel P. Berrange wrote:
It's Linux-specific, and it should be possible to disable it
Yes & no. The storage_backend_fs.c file is actually 3 backends all in one file.
- A directory based pool - A local filesystem based pool - A network filesystem based pool
The directory based pool only uses trivial POSIX apis like open/read/write/close/stat and is intended to be the one impl that is guarenteed available on all operating systems. Thus we delibrately don't disable the whole compilation of this file in the Makefile.am
Would be simpler to split out into separate files? This threw me.
Originally I thought it'd be easier to have them all in one file to make sharing of code between them easier. In retrospect this was a mistake and causes more pain than it solves, so I'd definitely be up for separating it out, and just putting decls for the shared functions in a storage_backend_dir.h for the filesystem pools to reference.
What compile errors do you get from the storage_backend_fs.c on Solaris when you run configure --without-storage-fs ?
"/export/build/johnlev/xvm/xvm-vi/libvirt.hg/src/storage_backend_fs.c", line 34: error: cannot find include file: <endian.h> "/export/build/johnlev/xvm/xvm-vi/libvirt.hg/src/storage_backend_fs.c", line 35: error: cannot find include file: <byteswap.h> "/export/build/johnlev/xvm/xvm-vi/libvirt.hg/src/storage_backend_fs.c", line 36: error: cannot find include file: <mntent.h> "/export/build/johnlev/xvm/xvm-vi/libvirt.hg/src/storage_backend_fs.c", line 81: error: undefined symbol: __BIG_ENDIAN
So line 36 needs moving within the #ifdef, and we need a general replacement for the endian stuff. I'm not sure what you're using from byteswap.h, but we can just define __*_ENDIAN if they're not, I think?
byteswap.h doesn't seem to be needed anymore, mntent definitely needs protecting. For endian.h, it looks like we can probably make use of an existing autoconf macro, AC_C_BIGENDIAN to set a config.h variable to say what our compiled endianness is, avoiding need for non-portable use of endian.h 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 :|
participants (3)
-
Daniel P. Berrange -
John Levon -
john.levon＠sun.com