-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for DKMS based packages #868
Conversation
When checking for the SPL Module.symvers file, a timeout can now be passed in which will pause the configure step while it waits for this file to be generated. By default, the configure behavior is unchanged as a timeout of 0 is used. If a positive number of seconds is passed, configure will wait that number of seconds for the Module.symvers file before moving on. The main motivation for this change was to support parallel execution of './configure && make' for the SPL and ZFS packages in preparation of supporting DKMS based packages. Signed-off-by: Prakash Surya <[email protected]>
This commit adds support for building a zfs-modules-dkms sub package built around Dynamic Kernel Module Support. This is to allow building packages using the DKMS infrastructure which is intended to ease the burden of kernel version changes, upgrades, etc. By default zfs-modules-dkms-* sub package will be built as part of the 'make rpm' target. Alternately, you can build only the DKMS module package using the 'make rpm-dkms' target. Examples: # To build packaged binaries as well as a dkms packages $ ./configure && make rpm # To build only the packaged binary utilities and dkms packages $ ./configure && make rpm-utils rpm-dkms Note: Only the RHEL 5/6, CHAOS 5, and Fedora distributions are supported for building the dkms sub package. Signed-off-by: Prakash Surya <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Issue #535
I also want to note that I had to set |
@prakash-surya: DKMS, as shipped by Ubuntu, retries zfs if its ./configure returns non-zero because spl is not ready. This happens on a second pass, which avoids the concurrency problem. This behavior is reliable for a dependency graph of depth 2, but probably not for a depth of 3. (ie: lustre-dkms -> zfs-dkms -> spl-dkms) Rebuilding the initrd should always succeed, even if the system doesn't actually need it for a ZFS installation. Perhaps you have a secondary problem if rebuilding the initrd fails. |
@dajhorn Interesting, I had wondered how you managed to resolve this in Ubuntu. OK, well I'd prefer not to count on that behavior from dkms so I think we'll go with the --with-spl-timeout option. Once merged your obviously welcome to use it if you like. We'll have to look in to the initrd thing as well. |
Move the logic for `access_stats` and `outstanding_ops` from ObjectAccessTrait implementors (s3, blob, oci) to the more general ObjectAccess layer. This reduces code duplication and ensures uniformity of semantics on different clouds. Change `ObjectAccess::inner` to `Box<dyn ObjectAccessTrait>`. No behavior change, code cleanup only
Change `BucketAccess::inner` to `Box<dyn BucketAccessTrait>`, as was done with `ObjectAccess::inner` in openzfs#868.
These commits, along with openzfs/spl#150, add initial support building DKMS based packages.