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.
- Add 64-bit user space atomic support obtained from an old version
of OpenSolaris which supported ppc. They are not all 100% fully
implemented by they are a good first step.
- Add powerpc ISA type.
- Strip out unused ISA defines to prevent any confusion.
Depending on your x86 architecture $target_cpu can evaluate to
any of the following (i386|i486|i586|i686). Since our local asm
uses only i386 instructions sed is used to map all of these to
i386 and sets $target_arch. Other arch's are not impacted.
Moved xdr_control() function from static inline in xdr.h in to a
new xdr.c file which was added to the libspl build. Additionally,
I have removed the 'xdr_bytesrec' typedef which shares the same
name as the struct. This is what Solaris does, but it's just asking
for trouble. It has been replaced with an 'xdr_bytesrec_t' typedef.
Most of these fixes appear to be harmless and should never occur.
However, there were a few cases in this patch which do concern me,
I doubt we're seeing them but they look possible... mainly in the
user tools.
Brian Behlendorf