ddiskit - Man Page

-h,  --help

Print a list of options. ddiskit will exit after this action, ignoring the remainder of the command line.

-v,  --verbosity

Increase output verbosity by 1. Value of 1 means verbose output (it toggles printing of most of executed commands and all warnings), and value of 2 is useful for debugging (it enables printing of all the executed commands output, actions, and messages). Value of 3 further increases output verbosity of issued rpm(1) commands.

Configuration option name: defaults.verbosity
Default value: 0

-p PROFILE, --profile PROFILE

Configuration profile to use. Please refer to the Configuration generation section for the additional information about profiles.

Configuration option name: defaults.profile
Default value: none; "default" is provided in package configuration

-R RES_DIR, --res-dir RES_DIR

Resources directory. Used as a base of evaluation for template and profile directory paths.

Configuration option name: defaults.res_dir
Default value: none; "/usr/share/ddiskit/" is a hard-coded default.

-T TEMPLATE_DIR, --template-dir TEMPLATE_DIR,

Templates directory, used as a base for searching for spec or module configuration templates. Please refer to the File path evaluation section for the information regarding template file path resolution.

Configuration option name: defaults.template_dir
Default value: none; "{res_dir}/templates" is a hard-coded default.

-P PROFILE_DIR, --profile-dir PROFILE_DIR

Profiles directory, used as a base for searching for profiles. Please refer to the File path evaluation section for the information regarding profile file path resolution.

Configuration option name: defaults.profile_dir
Default value: none; "{res_dir}/profiles" is a hard-coded default.

-d,  --dump-config

Dump the derived configuration after performing the action.

Configuration option name: defaults.dump_config
Default value: False

-o DUMP_CONFIG_NAME, --dump-config-name DUMP_CONFIG_NAME

Path to the file targeted for the configuration dump.

Configuration option name: defaults.dump_config_name
Default value: none; "{config}.generated" is a hard-coded default.

-q,  --quilt-enable

Enable quilt support. Please refer to the Quilt Integration section for the information regarding quilt integration. The option sets defaults.quilt_support configuration option to True.

-Q,  --quilt-disable

Disable quilt support. The option sets defaults.quilt_support configuration option to False.

-C KEY=VALUE, --config-option KEY=VALUE

Override arbitrary configuration option that have the name KEY with VALUE. The KEY should follow the "{[section_name.]key_name}" syntax, and defaults section is assumed in case section_name part is omitted. The argument can be used multiple times in order to override multiple options.

-c CONFIG, --config CONFIG

Path to the module configuration file.

Configuration option name: defaults.config
Default value: "module.config"

-t CONFIG_TEMPLATE, --config-template CONFIG_TEMPLATE

Configuration file template. Please refer to the File path evaluation section for the information regarding configuration template file path resolution.

Configuration option name: defaults.config_template
Default value: none; "config" is a hard-coded default.

-g GIT_DIRECTORY, --git-dir GIT_DIRECTORY

Path to .git directory containing repository from where source files should be checked out.

Configuration option name: defaults.git_dir
Default value: none

-r REVISION, --git-revision REVISION

Revision specification at which source files should be checked out from the repository.

Configuration option name: defaults.git_revision
Default value: "HEAD"

-d DIRECTORIES, --git-src-directory DIRECTORIES

Whitespace-separated list of paths which should be checked out from the repository.

Configuration option name: defaults.git_src_directory
Default value: none

-M MAJOR, --major MAJOR

Major version number of the distribution the package is built for (for example, "7" for RHEL 7.3).

Configuration option name: defaults.major
Default value: 7

-m MINOR, --minor MINOR

Minor version number of the distribution the package is built for (for example, "3" for RHEL 7.3).

Configuration option name: defaults.minor
Default value: 0

-c CONFIG, --config CONFIG

Path to the module configuration file.

Configuration option name: defaults.config
Default value: "module.config"

-t SPEC_TEMPLATE, --spec-template SPEC_TEMPLATE

RPM spec file template. Please refer to the File path evaluation section for the information regarding RPM spec template file path resolution.

Configuration option name: defaults.spec_template
Default value: none; "spec" is a hard-coded default.

-c CONFIG, --config CONFIG

Path to the module configuration file.

Configuration option name: defaults.config
Default value: "module.config"

-a, --tar-all

Tar all files, including hidden ones (files with names starting with dot). Otherwise, only files with names starting with non-dot character will be added to the source tarball. The option sets the value of the relevant configuration parameter to True. Note that this check is independent from the check controlled by the defaults.tar_strict configuration parameter.

Configuration option name: defaults.tar_all
Default value: False

-e, --tar-strict

Tar only expected files. Only the files with names matching the regular expression pattern provided in defaults.src_patterns configuration option will be added to the source tarball. The option sets the value of the relevant configuration parameter to True. Note that this check is independent from the check controlled by the defaults.tar_all configuration parameter.

Configuration option name: defaults.tar_strict
Default value: False

-s, --srpm

Force building of source RPM instead of binary one. ddiskit has several heuristics (whether host architecture is among architectures targeted by module, whether RPM build check passes) that detect possibility of binary RPM build and falls back to building source RPM only in case they indicated that binary RPM build is impossible; however, one can force building of source RPM instead of binary one with this switch. The option sets the value of the relevant configuration parameter to True.

Configuration option name: defaults.srpm
Default value: False

-m, --mock

Enable mock(1) usage for building RPM. See the MOCK SUPPORT section for additional information.

Configuration option name: defaults.mock
Default value: False

-r MOCK_CONFIG, --mock-config MOCK_CONFIG

Which mock configuration should be used for building RPM.

Configuration option name: defaults.mock_config
Default value: "default"

-l, --mock-offline

Whether to pass --offline option to mock.

Configuration option name: defaults.mock_offline
Default value: False

-O MOCK_OPTIONS, --mock-opts MOCK_OPTIONS

Additional options that have to be passed to mock invocations. Shell quoting is supported. Overwrites options set by previous -O and/or -A options.

Configuration option name: defaults.mock_opts
Default value: none

-A MOCK_OPTIONS, --mock-opts-append MOCK_OPTIONS

Additional options that have to be passed to mock invocations. Shell quoting is supported. Appends options to the options set by previous -O and/or -A options.

Configuration option name: defaults.mock_opts
Default value: none

-g LEVEL, --check-git-src LEVEL

Set the level of source code repository authenticity check. See the Source Code Verification section for the details.

Configuration option name: defaults.check_get_src
Default value: 0

-G, --generate-spec-on-build

Call the generate_spec action at the beginning of the build_rpm action execution. This saves for calling generate_spec action separately each time module configuration or patch list are changed (assuming that spec file does not need manual changes after generation).

Configuration option name: defaults.generate_spec_on_build
Default value: 0

-c CONFIG, --config CONFIG

Path to the module configuration file.

Configuration option name: defaults.config
Default value: "module.config"

-i ISOFILE, --isofile ISOFILE

File name for the output ISO.

Configuration option name: defaults.isofile
Default value: none; see also build_iso action description section.

-c CONFIG, --config CONFIG

Path to the module configuration file.

Configuration option name: defaults.config
Default value: "module.config"

-o DUMP_CONFIG_NAME, --dump-config-name DUMP_CONFIG_NAME

Name of the file where to store configuration dump. This is the same option as the -o option in the General options section, and present here only for convenience.

Configuration option name: defaults.dump_config_name
Default value: none; "{config}.generated" is a hard-coded default.

-c CONFIG, --config CONFIG

Path to the module configuration file.

Configuration option name: defaults.config
Default value: "module.config"

-g GIT_DIRECTORY, --git-dir GIT_DIRECTORY

Path to .git directory containing repository from where source files should be checked out.

Configuration option name: defaults.git_dir
Default value: none

-d KABI_DIRECTORY, --kabi-dest-dir KABI_DIRECTORY

Path to kABI symbol information files directory withing kernel source tree that is ought to be updated.

Configuration option name: defaults.kabi_dest_dir
Default value: none

-e, --extract-kmod

Extract kmods from RPMs and use their modversion data instead of RPM "Requires" tags. The option sets defaults.kabi_use_rpm_ko configuration option to True.

-E, --no-extract-kmod

Do not extract kmods from RPM and use data provided in "Requires" tags instead. The option sets defaults.kabi_use_rpm_ko configuration option to False.

-o, --overwrite

Overwrite existing kABI symbol information files. The option sets defaults.kabi_files_overwrite configuration option to 2.

-O, --no-overwrite

Do not overwrite existing kABI symbol information files. The option sets defaults.kabi_files_overwrite configuration option to 0.

-i, --overwrite-interactive

Ask user when a possibility of existing kABI symbol information file overwrite appears. The option sets defaults.kabi_files_overwrite configuration option to 1.

-t, --commit

Perform create a git commit with the affected kABI symbol files on success. The option sets defaults.kabi_commit configuration option to True.

-n, --no-commit

Do not perform create a git commit with the affected kABI symbol files on success. The option sets defaults.kabi_commit configuration option to False.

-m MESSAGE, --kabi-commit-message MESSAGE

Commit message that is supplied for the git commit with the affected kABI symbol files.

Configuration option name: defaults.kabi_commit
Default value: none

-M SYMVERS_PATH, --symvers-path SYMVERS_PATH

Path to a relevant kernel's Module.symvers file (for example, "/usr/src/kernels/KERNEL_VERSION.{arch}/Module.symvers", present in the kernel-devel RPM).

Configuration option name: defaults.symvers_path
Default value: none

-w WHITELIST_PATH, --kabi-whitelist WHITELIST_PATH

Path to a file containing a list of symbols already white listed, in Module.symvers format.

Configuration option name: defaults.kabi_whitelist
Default value: none

-b, --break-on-errors

Abort when a symbol version conflict is discovered. The option sets defaults.kabi_check_symvers_conflicts configuration option to 2.

-B, --no-break-on-version-conflicts

Continue processing even if a symbol version conflict is discovered. The option sets defaults.kabi_check_symvers_conflicts configuration option to 0.

-a, --ask-on-version-conflicts

Ask user what to do when a symbol version conflict is discovered. The option sets defaults.kabi_check_symvers_conflicts configuration option to 1.

In order to construct its configuration, ddiskit gathers configuration options from the multiple sources, then performs some fixed processing. The sources of configuration options are the following:

• Hard-coded defaults, present in ddiskit source code. These are mostly for default configuration search paths and for other values which are expected to be defined one way or another. Currently, it contains the following configuration options:

  • defaults section

    • res_dir = "/usr/share/ddiskit"
    • template_dir = "{res_dir}/templates"
    • profile_dir = "{res_dir}/profiles"
    • config_template = "config"
    • quilt_support = True
    • spec_template = "spec"
    • src_patterns = "^Kbuild$|^Kconfig$|^Makefile$|^.*.[ch]$"

  • global section

    • module_vendor = "ENTER_MODULE_VENDOR"
    • module_author = "ENTER_MODULE_AUTHOR"
    • module_author_email = "ENTER_MODULE_AUTHOR_EMAIL"
• The "package" configuration. It contains the rest of the configuration option defaults which should be defined for proper operation (like spec file generation). Package configuration is read from the fixed path "/usr/share/ddiskit/ddiskit.config" which is not expected to be modified by user or system administrator (and is usually overwritten by package update).
• The "site" configuration. Located in "/etc/ddiskit.config", this file is treated as a configuration file and is subject to possible changes by the system administrator.
• The "user" configuration. In case user wants some user-specific changes (like his own default values for global.module_author or global.module_author_email configuration options, as well as default profile), he should place it in ".ddiskitrc" file in his home directory.
• Profile. The profile in use is derived from defaults.profile and default.profile_dir configuration variables (see more in the File path evaluation section on how the path to the profile is evaluated). It contains overrides suitable for a particular use case (for example, the rh-testing profile contains spec file description suffix with a notice that the package provided is a testing package). Note that the values for aforementioned configuration variables can be overridden by -p and -P command line arguments.
• Module configuration. This file is usually called "module.config" (but can be overridden by -c command line argument) and contains module-specific configuration. It is usually generated from template by prepare_sources action and is self-documented in terms of what values user is expected to provide there.
• Command-line arguments. They update defaults section of the configuration dictionary, and usually have key name equal to the long option name, with dashes replaced with underscores. Configuration option name for each specific command line option is provided in the Options section. Unless explicitly specified (with default value being "none"), command line option always updates the configuration option value.

These files are applied one after another in aforementioned order, so the "last wins" rule applies. The exception from the rule are command line options, which take precedence at each point of configuration generation (during the profile path evaluation, for example).

The configuration files themselves are sectioned key-value files, syntax of which is described in the related Python module documentation, except for the interpolation part, which is home-grown and described in the section Configuration value evaluation.

Red Hat Enterprise Linux follows specific kernel package versioning scheme, and ddiskit employs it in order to generate proper dependencies on the kernel package. As a result, it expects that in places where kernel version is provided, this version follows specific scheme. More specifically, two version schemes are supported:

• Y-stream kernel version. This kernel package version is shipped as a part of General Availability release, and has the following format:

  kernel_version.kernel_patchlevel.kernel_sublevel-rhel_release.rpm_dist

  For example, RHEL 7.3 GA kernel has kernel version 3.10.0-514.el7. Consequently, it is expected that kernel_version, kernel_patchlevel, kernel_sublevel, rhel_release are decimal numbers (having no more than 1, 2, 2, and 4 digits, respectively), and rpm_dist part is provided in the form of "el<number>", where <number> is a 1-digit or 2-digit number not less than 6.

• Z-stream kernel version. These kernel packages are provided as a part of updates for the existing release (so-called Z-stream). The versions of these packages have the following format:

  kernel_version.kernel_patchlevel.kernel_sublevel-rhel_release[.update_release]+.rpm_dist

  The restrictions on the parts that also used for the Y-stream kernel package version description are the same, and update_release is a number that can have up to 3 digits. Example of a Z-stream kernel package version (RHEL 7.3 update from 2017-05-25): 3.10.0-514.21.1.el7.

Generally, it is expected that kernel module RPMs and Driver Update Disks are built for using along with the Y-stream GA kernel (and all the following Z-stream kernels, thanks to kABI compatibility), so when Z-stream kernel package version is detected, the user is warned about this. The differences between kernel package dependency generation in these cases are described in the Spec file generation section.

In order to enforce these checks, ddiskit uses regular expression-based approach: it checks the version provided in the defaults.kernel_version configuration variable against regular expressions set via the defaults.kernel_flex_version_re and defaults.kernel_fixed_version_re configuration options, which contain Python regular expressions (see Python re module documentation for details about regular expression syntax) for matching Y-stream and Z-stream kernel versioning scheme, respectively. In order to extract parts of kernel version described above, the following regular expression groups are used:

version

Kernel's major version (kernel_version in the description above).

patchlevel

Kernel's patch level (kernel_patchlevel).

sublevel

Kernel's sub-patch level (kernel_sublevel).

rpm_release

Major part of RPM release (rhel_release).

rpm_release_add

Remaining part of RPM release (update_release).

rpm_dist

RPM release dist part (rpm_dist).

The default values of the defaults.kernel_flex_version_re and defaults.kernel_fixed_version_re configuration options are set via other configuration options:

kernel_flex_verson_re   = {kernel_nvr_re}{kernel_dist_re}
kernel_fixed_version_re = {kernel_nvr_re}{kernel_fixed_re}{kernel_dist_re}

kernel_nvr_re   = (?P<version>[0-9]).(?P<patchlevel>[0-9]{1,2}).(?P<sublevel>[0-9]{1,2})-(?P<rpm_release>[0-9]{1,4})
kernel_fixed_re = (?P<rpm_release_add>(.[0-9]{1,3})+)
kernel_dist_re  = (?P<rpm_dist>.el([6-9]|[1-9][0-9]))

This allows for some flexibility in case some tuning of these checks is needed.

After the configuration has been constructed (and in case module configuration is present), it is subject to a set of checks:

• Whether global and spec_file configuration sections are present.
• Whether all configuration options in global and spec_file sections have non-default values. Default value is a value which is the concatenation of "ENTER_" and upper-cased configuration key name ("ENTER_MODULE_NAME" for spec_file.module_name configuration option, for example). The exception is spec_file.firmware_version option, in case spec_file.firmware_include configuration options is set to False.
• Whether spec_file.kernel_version has proper format (only Y-stream and Z-stream kernel versions are accepted, see the Kernel package versioning scheme section for the acceptable version string format configuration details).
• Whether spec_file.module_name, spec_flie.module_version, and spec_file.module_rpm_release configuration options contain only characters accepted by RPM (alphanumeric plus '.', '-', '_', '+', '%', '{', '}' for spec_file.module_name; alphanumeric plus '.', '_', '+', '%', '{', '}', '~' for spec_flie.module_version and spec_file.module_rpm_release).

Paths to various external resource files (like templates and profiles) are evaluated based on provided resource directory and name using the following algorithm:

• If resource name does not have slashes, then it is considered that this name refers to the file in the provided directory.
• Otherwise, it is interpreted as a path relative to the current working directory (which is the directory the where module configuration resides).

For example, profile "my-profile" is searched relative to profile directory (stored in the defaults.profile_dir configuration option, "/usr/share/ddiskit/profiles" by default), but profile "./my-profile" is searched relative to module's configuration directory.

Configuration option values can reference other configuration options using the "{[section_name.]key_name}" syntax. If section is not present, it is assumed that the referenced key is in the same section as the value which references it. If the referenced key is not found, no substitution occurs.

For example, let's assume the following configuration file:

[foo]
foo = aaa {bar} {bar.baz}
bar = bbb {baz} {bar.foo}

[bar]
foo = ccc {baz}
bar = ddd {foo.foo}
baz = eee

After the evaluation, foo.foo key would have the value "aaa bbb {baz} ddd ccc eee eee", foo.bar would equal to "bbb {baz} ccc eee", bar.foo would be "ccc eee", and bar.bar is "ddd ccc eee".

Circular dependencies are not explicitly resolved, there's only substitution depth limit present (which is set to 8 currently).

The values which are treated as boolean can have the following (case-insensitive) values in order to indicate that the value should be evaluated to True: 1, t, y, true, or yes. In order to indicate False value, one of the following strings may be used: 0, f, n, false, or no. In case configuration value doesn't evaluate to True or False value, it is evaluated as None. None value is treated as False in most places, but sometimes it is important to provide specific choice, and in these cases error would occur if boolean value was evaluated to None.

Before spec file generation takes place, additional configuration processing is performed:

• spec_file.source_patches and spec_file.source_patches_do generated in accordance with a lexicographically sorted list of patch files found in the patch directory: src/patch relative to the current working directory (except when quilt(1) integration is enabled; see the Quilt Integration section for details). spec_file.source_patches contains lines in the "PatchN: patch-file-name" format, and spec_file.source_patches_do contains lines in the "%patchN -p1" format. As a result, first configuration variable is suitable for patch file list description, and second is useful in the %prep section for patch applying. If the default.quilt_support configuration option is enabled, file named series is ignored in the patch directory.
• spec_file.firmware_files configuration variable contains list of files found in the src/firmware directory with the /lib/firmware/ directory prepended, which is suitable for the %files section of the firmware sub-package.
• spec_file.firmware_files_install configuration variable contains list for firmware file installation commands in the format "install -m 644 -D source/firmware/firmware-file-path $RPM_BUILD_ROOT/lib/firmware/firmware-file-path", which is suitable for the %install section of the firmware sub-package.
• spec_file.firmware_begin configuration option is set to "%if 1" or "%if 0" when the spec_file.firmware_include configuration variable is true or not, respectively.
• spec_file.firmware_end configuration variable is set to "%endif".
• spec_file.date is set to the current date and time in "%a %b %d %Y" strftime(3) format, if this variable hasn't been set already.

• spec_file.kernel_requires is formatted as following (if the variable hasn't been set already):

  • if the spec_file.kernel_version_min configuration option contains a non-empty value, it is set to

    Requires:    kernel >= spec_file.kernel_version_min

  • otherwise, if the spec_file.kernel_version_dep configuration option contains a non-empty value, it is set to

    Requires:    kernel = spec_file.kernel_version_dep

  • otherwise, it is set to

    Requires:    kernel >= kernel_version-kernel_release.kernel_dist
    Requires:    kernel <  kernel_version-(kernel_release + 1).kernel_dist

    if the spec_file.kernel_version configuration option contains a Y-stream kernel version, or

    Requires:    kernel = kernel_version-kernel_release.kernel_dist

    if the spec_file.kernel_version configuration option contains a Z-stream kernel version (please refer to the Kernel package versioning scheme section for the additional details regarding Y-stream and Z-stream versions).

  If spec_file.kernel_version configuration option is not set and mock support is enabled, its value is defaulted to the latest version of the kernel-devel package available in the mock environment.

• spec_file.module_requires is set to spec_file.dependencies value with the "Requires: " string prepended, if the variable hasn't been set already. Note that this special configuration variable is deprecated, present only for the backward compatibility, and this special value generation may be removed in the future.

After this configuration processing, parts of the spec template in the "%{[section_name.]key_name}" format (note the presence of percent sign in comparison to the syntax used for configuration option substitution) are replaced with evaluated configuration values. If no appropriate configuration has been found, no replacement occurs. If configuration option evaluates to empty string, %{nil} is inserted into the resulting spec file.

Prepare initial file and directory structure. This action creates directories where various files are expected to be placed and creates (into a file set in --config option) module configuration from the template file (which path is determined by the defaults.template_dir and defaults.config_template configuration variables; please refer to the File path evaluation section for the module configuration template path derivation process). The action creates the following directory hierarchy:

• rpm - directory for storing rpmbuild(1) artifacts.

  • BUILD - build directory, used by rpmbuild(1).
  • BUILDROOT - RPM build root.
  • RPMS - directory where resulting binary RPMs are stored.
  • SOURCES - directory where source tarball and patches are stored.
  • SPECS - directory where generated spec file is placed.
  • SRPMS - directory where resulting source RPM is stored.

• src - directory where module sources are expected to be placed. There are not explicit constrains on the kernel module source file layout, but it is expected that the main make file is placed in a directory provided in the spec_file.module_build_dir configuration variable.

  • patches - directory with patches that should be applied to the source.
  • firmware - firmware files.

Additionally, if the defaults.git_src_directory configuration option (which, in turn, defaults to the value of the spec_file.module_build_dir configuration option, provided the latter is non-empty) is set, source files placed inside directories listed in this whitespace-separated list checked out (inside the src directory) from the repository pointed by the defaults.git_dir configuration option at the revision which specification is set in the defaults.git_revision configuration option (the actual revision to checkout is the output of git rev-parse(1) command invocation with the aforementioned specification supplied to it).

Before configuration template is processed, the following configuration options are also set:

• spec_file.module_build_dir - set to the value of first element of whitespace-separated list stored in the defaults.git_src_directory configuration option, or to "ENTER_MODULE_BUILD_DIR", if it is empty.
• spec_file.git_hash - set to the value returned by get rev-parse(1) call with defaults.git_revision revision specification supplied.

Generate spec file from the spec template (which path is determined by the defaults.template_dir and defaults.spec_template configuration variables; please refer to the File path evaluation section for spec template path derivation process) using process described in Spec file generation section. As a result of the execution of this action, the "rpm/SPECS/{spec_file.module_name}.spec" file is generated. During the generation process, the presence of kernel headers for the target kernel version and architectures is also checked, and warning message is printed in case some of them are not present; this check doesn't affect spec file generation process, however.

The RPM build action includes several steps:

• Check for the module configuration file presence (provided in defaults.config configuration variable via the --config command line option). Since some configuration values should be derived directly from it, its absence makes the whole operation senseless, thus the early bailout.

• Generate (if the defaults.generate_spec_on_build configuration option is set to True) or check (if the defaults.check_spec_on_build configuration option is set to positive value) spec file. Depending on the check level provided in the defaults.check_spec_on build configuration option, the latter check may lead to warning or to the termination of the action:

  0

  Do not perform the spec file check.

  1

  Perform spec file comparison and issue warning in case generated and existing spec files differ.

  2

  Perform spec file comparison and issue warning in case generated and existing spec files differ, user is asked whether he wants to continue.

  3

  Perform spec file comparison and abort action execution in case of any errors (during spec file generation or comparison).

  No spec file comparison is performed (regardless of the defaults.check_spec_on_build configuration option value) if spec file generation is enabled (obviously).

• Check for Makefile presence. Presence of file named Makefile somewhere in the source tree allows for passing this check. Absence of Makefile leads to early termination with a relevant exit code (please refer to the Exit Status section for details).
• In case quilt integration (specified via the configuration option default.quilt_support) is enabled, quilt patches are de-applied.

• Source tarball creation. Tar file named "rpm/SOURCES/{spec_file.module_name}-{global.module_vendor}-{spec_file.module_version}.tar.bz2" is created, and files present in the src directory added to it, with the following exceptions:

  • patches subdirectory is skipped.
  • All RPM files present in the top level of the src directory are skipped.
  • Files present in the firmware source subdirectory are skipped in case boolean configuration option spec_file.firmware_include is set to False. In case there are files present in this directory, warning message is displayed regarding the matter.
  • Hidden files (files beginning with dot) are skipped, unless the defaults.tar_all configuration option (controlled via the --tar-all action-specific command line option) is set to True.
  • Only files matching the pattern set in the defaults.src_patterns configuration option are added, if the defaults.tar_strict configuration option (controlled via the --tar-strict action-specific command line option) is set to True. The default pattern includes only *.c, *.h, Makefile, Kbuild, and Kconfig files, which should be suitable for the most cases.
• All files from the src/patches directory are copied to the rpm/SOURCES directory.
• If current host architecture is among architectures provided in the spec_file.kernel_arch architectures, rpmbuild check (rpmbuild -bc --nobuild) succeeded, and the defaults.srpm configuration option (controlled via the --srpm action-specific command line option) is not enabled, an attempt to build binary RPM is performed. Otherwise, a source RPM is built.
• In case quilt integration (specified via the configuration option default.quilt_support) is enabled, quilt patches are applied back.

This action takes list of files and directories that should be placed on the Driver Update Disk as a non-option arguments. It performs the following steps:

• Iterate over the files provided in arguments (recursively descending into directories) and add to the list of candidate files which satisfy the following criteria:

  • file name ends with ".rpm",
  • rpmquery(1) successfully retrieves information regarding RPM architecture from the package,
  • RPM is a binary package or RPM is a source package and the global.include_srpm configuration option is enabled,
  • RPM is not a debug information package (RPM has group other than "Development/Debug"),
  • RPM has a valid GPG signature (if case GPG signature check is enabled; see RPM SIGNATURE VERIFICATION section for the additional information).
• All satisfying candidates then copied in a temporary directory. Source RPMs are placed in src subdirectory in the disk hierarchy, and binary RPMs are placed in rpms/arch subdirectory, where arch is the architecture of the binary RPM (with all variants of i386, ..., i686 RPM architecture placed in the i386 subdirectory).
• RPM repository metadata is generated (using the createrepo(1) command) in each of the aforementioned binary RPM directories.
• rhdd3 file containing Driver Update Disk signature is created in the temporary directory.
• ISO image is created with the mkisofs(1) command. The name of the ISO is provided in the defaults.isofile option (which can be set via the --isofile action-specific command line option). In case no explicit ISO file name is provided, it is generated as "dd-{spec_file.module_name}-{spec_file.module_version}-{spec_file.module_rpm_release}.{spec_file.rpm_dist}.iso", or, in case one of values of these configuration options is not a string, simply "dd.iso".

Dumps configuration dictionary as it has been evaluated by a process described in the Configuration generation section. Output file for the dump is set in the defaults.dump_config_name option.

Generate files with kABI symbol information in the Red Hat Enterprise Linux kernel git repository and optionally commit the changes. The action processes kmods and RPMs provided in the positional arguments, collecting versions (checksums) of symbols present in module information sections and/or "Requires" RPM tags, and adds to the git repository files corresponding to symbols not yet added into it. The process is controlled via the following configuration options:

defaults.kabi_use_rpm_ko

Whether to process kmod files inside the provided RPMs instead of RPM files themselves.

defaults.symvers_symbol_re (string)

Regular expression used for parsing lines in symvers files. Expected to contain ver, symbol, file, and export groups.

defaults.kabi_files_overwrite (int)

Whether to overwrite kABI files if the files with the same name already exist. Can take the following values:

0

Do not overwrite existing kABI files.

1

Ask user on each possible overwrite.

2

Overwrite existing kABI files.

defaults.kabi_check_symvers_conflicts (int)

Whether to abort the action when a symbol version conflict (between newly added symbol and Module.symvers or kABI white list) is detected. Can take the following values:

0

Continue processing.

1

Ask user on each occesion.

2

Abort the action.

defaults.kabi_commit (bool)

Whether to commit the changes at the end of the successful kABI files update.

defaults.symvers_path (string) [1]

Path to the kernel's Module.symvers file.

defaults.kabi_whitelist (string) [1]

Path to the kABI white list (in Module.symvers format).

defaults.git_dir (string)

Path to the kernel's git repository.

defaults.kabi_dest_dir (string) [2]

Path in the kernel's repository to the directory with kABI symbol files.

defaults.kabi_file_name_pattern (string) [2]

Name of a kABI symbol file.

defaults.kabi_file_template (string) [2]

Contents template of a kABI symbol file.

defaults.kabi_commit_log_template (string) [2]

Template of a line in the commit log regarding specific kABI symbol file.

defaults.kabi_commit_message (string) [2]

Commit message used for the git commit, if defaults.kabi_commit configuration option is enabled.

Notes:

[1]

The arch variable is overridden with with architecture of the kmod currently being processed ("x86_64" or "ppc64le", for example).

[2]

There are multiple overrides take place during evaluation of the values:

sym

Symbol being processed.

arch

Architecture of the kmod being processed.

ver

Version (checksum) of the symbol being processed.

kmod_file

File name of the kmod being processed.

kernel_file

Path to the file inside the kernel tree that contains the definition of the symbol being processed.

kernel_export

Type of the export ("EXPORT_SYMBOL", for example).

As of now, the rh-release profile contains some useful default values for the aforementioned configuration options.