This include updating all the Makefile.am to have the correct
include paths and libraries. In addition, the zlib m4 macro was
updated to more correctly integrate with the Makefiles. And I
added two new macros libblkid and libuuid which will be needed by
subsequent commits for blkid and uuid support respectively. The
blkid support is optional, the uuid support is mandatory for libefi.
This change extends the existing in-tree test infrastructure such
that it can also be run as part of a the installed package. This
simplifies testing on multiple systems and is generally all around
useful. The scripts may still be run in-tree and will use the
in-tree build products as long as .script-config exists.
This change extends the existing in-tree test infrastructure such
that it can also be run as part of a the installed package. This
simplifies testing on multiple systems and is generally all around
useful. The scripts may still be run in-tree and will use the
in-tree build products as long as .script-config exists.
2.6.22 API change
Unused destroy_dirty_buffers arg removed from prototype.
2.6.24 API change
Empty write barriers are now supported and we should use them.
2.6.24 API change
Size argument dropped from bio_endio and bi_end_io, because the
bi_end_io is only called once now when the request is complete.
There is no longer any need for a size argument. This also means
that partial IO's are no longer possibe and the end_io callback
should not check bi->bi_size. Finally, the return type was updated
to void.
2.6.28 API change
open/close_bdev_excl() renamed to open/close_bdev_exclusive().
2.6.29 API change
BIO_RW_SYNC renamed to BIO_RW_SYNCIO.
Modern kernel build systems at least post 2.6.16 will set this properly
so we should not. In fact post 2.6.28 the include headers have moved
under arch so the guess we make here is completely wrong. Letting
the kernel build system set this ensure it will be correct. Also
drop the ulimit from the Makefile which, not surprisingly, turns out
to be very non-portable. If your expecting failures set the ulimit
in your shell before kicking off the test suite.
Futher testing on my powerpc system revealed that the powerpc
specific atomic implemetation was flawed. Rather than spending
a lot of time correctly reimplementing it in assembly I have
reworked it in to a 100% generic version. The generic version
will not perform well but it does provide correct sematics. It
will be used only when there is no architecture specific version
available. These changes do not impact x86_64 and x86 which have
have correct native implementations.
when used to generate source rpms. These should not be fatal
because we actually don't need them until we build the source
rpm. When doing mock build this is important because these
dependent rpms will only be installed if they are specificed
in the source rpms spec file.
These changes bring the zfs-0.4.4 tree in to compliance with
the spl-0.4.4 packaging changes. The bottom line is 2 source
rpms and 4 binary rpms will now be generated when creating
packages there will be:
zfs-<version>.src.rpm
- Fully rebuildable source rpm for libzfs and utils.
zfs-modules-<version>.src.rpm
- Fully rebuildable source rpm for kernel modules.
zfs-<version>.<arch>.rpm
- Binary rpm for libzfs and utils. The utils in this package are
compatible with all zfs-module rpms of the same version.
zfs-devel-<version>.<arch>.rpm
- Binary rpm containing headers for building against libzfs libraries.
zfs-modules-<verion>-<kernel>.arch.rpm
- Binary rpm containing the kernel modules for a specific kernel build.
The package name contains the kernel version and you should have one
of these packages installed to match every kernel on your system.
zfs-modules-devel-<verion>-<kernel>.arch.rpm
- Binary rpm containing development header and module symbols needed
for building additional kernel modules which are dependent on the
zfs module stack.
Expect minor interations on these changes as I validate they work
properly on CHAOS, RHEL, Fedora, and SLES style distros.
- ZFS_AC_KERNEL updated to exclude -obj entries in /usr/src/ when
attempting to automatically detect your kernel source.
- ZFS_AC_KERNEL check for *-obj directory when attempting to
detect the objects for your kernel source.
- ZFS_AC_SPL updated to additionally check for Modules.symvers build
product. This seems to be specific to SLES system, for Vanilla,
Fedora, RHEL, and Chaos kernels the symbol file is just called
Module.symvers.
- ZFS_CHECK_SYMBOL_EXPORT also should also check the exported SPL
symbols in addition to the exported core kernel systems.
This is used when you need to configure the project but you don't
actually intend to build it. Thus you don't really need access to
either the kernel or spl headers and symbols. At Livermore I use
this when I only intend to use the 'make dist' or 'make srpm' target.
All these errors are now either addressed in a gcc-* topic branch, or
in whatever branch the original warning was introduced by (i.e. I fixed
the bug which just went unnoticed until now due to the compiler flags)
An update to the build system to properly support all commonly
used Makefile targets these include:
make all # Build everything
make install # Install everything
make clean # Clean up build products
make distclean # Clean up everything
make dist # Create package tarball
make srpm # Create package source RPM
make rpm # Create package binary RPMs
make tags # Create ctags and etags for everything
Extra care was taken to ensure that the source RPMs are fully
rebuildable against Fedora/RHEL/Chaos kernels. To build binary
RPMs from the source RPM for your system simply run:
rpmbuild --rebuild zfs-x.y.z-1.src.rpm
This will produce two binary RPMs with correct 'requires'
dependencies for your kernel. One will contain all zfs modules
and support utilities, the other is a devel package for compiling
additional kernel modules which are dependant on the zfs.
zfs-x.y.z-1_<kernel version>.x86_64.rpm
zfs-devel-x.y.2-1_<kernel version>.x86_64.rpm
of the kernel specific build info in to config/kernel,
likewise and user specific build flags should go in
config/user. This seems like a reasonable way to go.
Brian Behlendorf