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.
The extra call to the constructor was there to reinitialize the non-
trivial primatives in the dnode (lists, mutexs, condvars, avl tree, etc).
This was safe, although not exactly clean, on Solaris because none of
the primitives allocate memory. In the Linux port this is not true.
To keep stack usage to a minimum several of the primatives dynamically
allocate memory thus initializing them twice results in a memory leak.
This patch resolves this problem for Solaris and Linux by ensuring all
*_inits are called in the constructor, and all *_destroys are called
in the destructor. Additionally we ensure that all dnode objects are
properly deconstructed before being freed to the slab, and when the
objects are allocated from the slab all required data members are
explicity initialized to correct values.
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.
The previous code was not wrong, but this prevents gcc from warning
us about missing cases for these known safe switch statements. The
-Wno-missing-cases can now be removed to detect places where we
accidentally forgot a case.
compile option. In most case the variables are only unused when
debugging is disabled (ASSERT) however they do waste stack if that
case if the compiler doesn't optimize it out (it should). But more
importantly disabling this warning prevent us from noticing legit
unused variables accidentally left in other place of the code.
Brian Behlendorf