neulab/tldr huggingface dataset:
Arguments ending in .ml are taken to be source files for compilation unit implementations. Implementations provide definitions for the names exported by the unit, and also contain expressions to be evaluated for their side-effects.  From the file x.ml, the ocamlopt(1) compiler produces two files: x.o, containing native object code, and x.cmx, containing extra information for linking and optimization of the clients of the unit. The compiled implementation should always be referred to under the name x.cmx (when given a .o file, ocamlopt(1) assumes that it contains code compiled from C, not from OCaml).
The implementation is checked against the interface file x.mli (if it exists) as described in the manual for ocamlc(1).
Arguments ending in .cmx are taken to be compiled object code.  These files are linked together, along with the object files obtained by compiling .ml arguments (if any), and the OCaml standard library, to produce a native-code executable program. The order in which .cmx and .ml arguments are presented on the command line is relevant: compilation units are initialized in that order at run-time, and it is a link-time error to use a component of a unit before having initialized it. Hence, a given x.cmx file must come before all .cmx files that refer to the unit x.
Arguments ending in .cmxa are taken to be libraries of object code.  Such a library packs in two files lib.cmxa and lib.a a set of object files (.cmx/.o files). Libraries are build with ocamlopt -a (see the description of the -a option below). The object files contained in the library are linked as regular .cmx files (see above), in the order specified when the library was built. The only difference is that if an object file contained in a library is not referenced anywhere in the program, then it is not linked in.
Arguments ending in .c are passed to the C compiler, which generates a .o object file. This object file is linked with the program.
Arguments ending in .o or .a are assumed to be C object files and libraries. They are linked with the program.
The output of the linking phase is a regular Unix executable file. It does not need ocamlrun(1) to run.
ocamlopt.opt is the same compiler as ocamlopt, but compiled with itself instead of with the bytecode compiler ocamlc(1).  Thus, it behaves exactly like ocamlopt, but compiles faster.  ocamlopt.opt is not available in all installations of OCaml.
The following command-line options are recognized by ocamlopt(1).
-a     Build a library (.cmxa/.a file) with the object files (.cmx/.o files) given on the command line, instead of linking them into an executable file. The name of the library must be set with the -o option.
If -cclib or -ccopt options are passed on the command line, these options are stored in the resulting .cmxa library.  Then, linking with this library automatically adds back the -cclib and -ccopt options as if they had been provided on the command line, unless the -noautolink option is given. Additionally, a substring $CAMLORIGIN inside a  -ccopt options will be replaced by the full path to the .cma library, excluding the filename.
-annot Deprecated since OCaml 4.11. Please use -bin-annot instead.
-cc ccomp Use ccomp as the C linker called to build the final executable and as the C compiler for compiling .c source files.
-cclib -llibname Pass the -llibname option to the linker. This causes the given C library to be linked with the program.
-ccopt option Pass the given option to the C compiler and linker. For instance, -ccopt -Ldir causes the C linker to search for C libraries in directory dir.
-compact Optimize the produced code for space rather than for time. This results in smaller but slightly slower programs. The default is to optimize for speed.
-config Print the version number of ocamlopt(1) and a detailed summary of its configuration, then exit.
-for-pack module-path Generate an object file (.cmx and .o files) that can later be included as a sub-module (with the given access path) of a compilation unit constructed with -pack.  For instance, ocamlopt -for-pack P -c A.ml will generate a.cmx and a.o files that can later be used with ocamlopt -pack -o P.cmx a.cmx.
-g     Add debugging information while compiling and linking. This option is required in order to produce stack backtraces when the program terminates on an uncaught exception (see ocamlrun(1)).
-I directory Add the given directory to the list of directories searched for compiled interface files (.cmi), compiled object code files (.cmx), and libraries (.cmxa). By default, the current directory is searched first, then the standard library directory. Directories added with -I are searched after the current directory, in the order in which they were given on the command line, but before the standard library directory. See also option -nostdlib.
-inline n Set aggressiveness of inlining to n, where n is a positive integer. Specifying -inline 0 prevents all functions from being inlined, except those whose body is smaller than the call site. Thus, inlining causes no expansion in code size. The default aggressiveness, -inline 1, allows slightly larger functions to be inlined, resulting in a slight expansion in code size. Higher values for the -inline option cause larger and larger functions to become candidate for inlining, but can result in a serious increase in code size.
-insn-sched Enables the instruction scheduling pass in the compiler backend.
-linkall Force all modules contained in libraries to be linked in. If this flag is not given, unreferenced modules are not linked in. When building a library (-a flag), setting the -linkall flag forces all subsequent links of programs involving that library to link all the modules contained in the library.  When compiling a module (option -c), setting the -linkall option ensures that this module will always be linked if it is put in a library and this library is linked.
-linscan Use linear scan register allocation.  Compiling with this allocator is faster than with the usual graph coloring allocator, sometimes quite drastically so for long functions and modules. On the other hand, the generated code can be a bit slower.
-noautolink When linking .cmxa libraries, ignore -cclib and -ccopt options potentially contained in the libraries (if these options were given when building the libraries).  This can be useful if a library contains incorrect specifications of C libraries or C options; in this case, during linking, set -noautolink and pass the correct C libraries and options on the command line.
-nodynlink Allow the compiler to use some optimizations that are valid only for code that is never dynlinked.
-no-insn-sched Disables the instruction scheduling pass in the compiler backend.
-nostdlib Do not automatically add the standard library directory to the list of directories searched for compiled interface files (.cmi), compiled object code files (.cmx), and libraries (.cmxa). See also option -I.
-o exec-file Specify the name of the output file produced by the linker. The default output name is a.out, in keeping with the Unix tradition. If the -a option is given, specify the name of the library produced. If the -pack option is given, specify the name of the packed object file produced.  If the -output-obj option is given, specify the name of the output file produced. If the -shared option is given, specify the name of plugin file produced.  This can also be used when compiling an interface or implementation file, without linking, in which case it sets the name of the cmi or cmo file, and also sets the module name to the file name up to the first dot.
-opaque When compiling a .mli interface file, this has the same effect as the -opaque option of the bytecode compiler. When compiling a .ml implementation file, this produces a .cmx file without cross- module optimization information, which reduces recompilation on module change.
-output-obj Cause the linker to produce a C object file instead of an executable file. This is useful to wrap OCaml code as a C library, callable from any C program. The name of the output object file must be set with the -o option.  This option can also be used to produce a compiled shared/dynamic library (.so extension).
-pack  Build an object file (.cmx and .o files) and its associated compiled interface (.cmi) that combines the .cmx object files given on the command line, making them appear as sub-modules of the output .cmx file.  The name of the output .cmx file must be given with the -o option.  For instance, ocamlopt -pack -o P.cmx A.cmx B.cmx C.cmx generates compiled files P.cmx, P.o and P.cmi describing a compilation unit having three sub-modules A, B and C, corresponding to the contents of the object files A.cmx, B.cmx and C.cmx.  These contents can be referenced as P.A, P.B and P.C in the remainder of the program.
The .cmx object files being combined must have been compiled with the appropriate -for-pack option.  In the example above, A.cmx, B.cmx and C.cmx must have been compiled with ocamlopt -for-pack P.
Multiple levels of packing can be achieved by combining -pack with -for-pack.  See The OCaml user's manual, chapter "Native-code compilation" for more details.
-pp command Cause the compiler to call the given command as a preprocessor for each source file. The output of command is redirected to an intermediate file, which is compiled. If there are no compilation errors, the intermediate file is deleted afterwards.
-principal Check information path during type-checking, to make sure that all types are derived in a principal way. All programs accepted in -principal mode are also accepted in default mode with equivalent types, but different binary signatures.
-S     Keep the assembly code produced during the compilation. The assembly code for the source file x.ml is saved in the file x.s.
-stop-after pass Stop compilation after the given compilation pass. The currently supported passes are: parsing, typing, scheduling, emit.
-save-ir-after pass Save intermediate representation after the given compilation pass. The currently supported passes are: scheduling.
-shared Build a plugin (usually .cmxs) that can be dynamically loaded with the Dynlink module. The name of the plugin must be set with the -o option. A plugin can include a number of OCaml modules and libraries, and extra native objects (.o, .a files).  Building native plugins is only supported for some operating system. Under some systems (currently, only Linux AMD 64), all the OCaml code linked in a plugin must have been compiled without the -nodynlink flag. Some constraints might also apply to the way the extra native objects have been compiled (under Linux AMD 64, they must contain only position-independent code).
-strict-sequence The left-hand part of a sequence must have type unit.
-unsafe Turn bound checking off for array and string accesses (the v.(i)ands.[i] constructs). Programs compiled with -unsafe are therefore faster, but unsafe: anything can happen if the program accesses an array or string outside of its bounds. Additionally, turn off the check for zero divisor in integer division and modulus operations.  With -unsafe, an integer division (or modulus) by zero can halt the program or continue with an unspecified result instead of raising a Division_by_zero exception.
-verbose Print all external commands before they are executed, in particular invocations of the assembler, C compiler, and linker.
-version or -vnum Print the version number of the compiler in short form (e.g. "3.11.0"), then exit.
-w warning-list Enable, disable, or mark as fatal the warnings specified by the argument warning-list.  See ocamlc(1) for the syntax of warning- list.
-warn-error warning-list Mark as fatal the warnings specified in the argument warning-list. The compiler will stop with an error when one of these warnings is emitted.  The warning-list has the same meaning as for the -w option: a + sign (or an uppercase letter) marks the corresponding warnings as fatal, a - sign (or a lowercase letter) turns them back into non-fatal warnings, and a @ sign both enables and marks as fatal the corresponding warnings.
OPTIONS FOR THE IA32 ARCHITECTURE The IA32 code generator (Intel Pentium, AMD Athlon) supports the following additional option:
-ffast-math Use the IA32 instructions to compute trigonometric and exponential functions, instead of calling the corresponding library routines. The functions affected are: atan, atan2, cos, log, log10, sin, sqrt and tan.  The resulting code runs faster, but the range of supported arguments and the precision of the result can be reduced.  In particular, trigonometric operations cos, sin, tan have their range reduced to [-2^64, 2^64].
OPTIONS FOR THE AMD64 ARCHITECTURE The AMD64 code generator (64-bit versions of Intel Pentium and AMD Athlon) supports the following additional options:
-fPIC  Generate position-independent machine code.  This is the default.
-fno-PIC Generate position-dependent machine code.
The PowerPC code generator supports the following additional options:
-flarge-toc Enables the PowerPC large model allowing the TOC (table of contents) to be arbitrarily large.  This is the default since 4.11.
-fsmall-toc Enables the PowerPC small model allowing the TOC to be up to 64 kbytes per compilation unit.  Prior to 4.11 this was the default behaviour.  \nd{options}
The ARM code generator supports the following additional options:
-farch=armv4|armv5|armv5te|armv6|armv6t2|armv7 Select the ARM target architecture
-ffpu=soft|vfpv2|vfpv3-d16|vfpv3 Select the floating-point hardware
-fPIC  Generate position-independent machine code.
-fno-PIC Generate position-dependent machine code.  This is the default.
-fthumb Enable Thumb/Thumb-2 code generation
-fno-thumb Disable Thumb/Thumb-2 code generation
The default values for target architecture, floating-point hardware and thumb usage were selected at configure-time when building ocamlopt itself. This configuration can be inspected using ocamlopt -config. Target architecture depends on the "model" setting, while floating-point hardware and thumb support are determined from the ABI setting in "system" ( linux_eabiorlinux_eabihf).
ocamlc(1). The OCaml user's manual, chapter "Native-code compilation".
BROWSER(1)                     Browser User Manual                    BROWSER(1)
browser - File manager and image viewer
browser [-D | -I | -L | -T] [directory...]
browser is a program that lists and manages files.
-D Start the file manager in detailed view.
-I Start the file manager in icon view.
-L Start the file manager in list view.
-T Start the file manager in thumbnail view.
A list of directories to browse can also be provided directly on the command line.
Issues can be listed and reported at http://www.defora.org/os/project/bug_list/230/Browser.
copy(1), delete(1), desktop(1), desktopctl(1), move(1), open(1), properties(1), view(1)
Pierre Pronchery <khorben@defora.org> Code and documentation.
Copyright Â© 2012, 2013 Pierre Pronchery <khorben@defora.org>
This manual page was written for the DeforaOS Project (and may be used by others).
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU General Public License, Version 3 as published by the Free Software Foundation.
FINDMNT(8)                    System Administration                   FINDMNT(8)
findmnt - find a filesystem
findmnt [options]
findmnt [options] device|mountpoint
findmnt [options] [--source] device [--target path|--mountpoint mountpoint]
findmnt will list all mounted filesystems or search for a filesystem. The findmnt command is able to search in /etc/fstab, /etc/mtab or /proc/self/mountinfo. If device or mountpoint is not given, all filesystems are shown.
The device may be specified by device name, major:minor numbers, filesystem label or UUID, or partition label or UUID. Note that findmnt follows mount(8) behavior where a device name may be interpreted as a mountpoint (and vice versa) if the --target, --mountpoint or --source options are not specified.
The command-line option --target accepts any file or directory and then findmnt displays the filesystem for the given path.
The command prints all mounted filesystems in the tree-like format by default.
-A, --all Disable all built-in filters and print all filesystems.
-a, --ascii Use ascii characters for tree formatting.
-b, --bytes Print the SIZE, USED and AVAIL columns in bytes rather than in a human-readable format.
-C, --nocanonicalize Do not canonicalize paths at all. This option affects the comparing of paths and the evaluation of tags (LABEL, UUID, etc.).
-c, --canonicalize Canonicalize all printed paths.
-D, --df Imitate the output of df(1). This option is equivalent to -o SOURCE,FSTYPE,SIZE,USED,AVAIL,USE%,TARGET but excludes all pseudo filesystems. Use --all to print all filesystems.
-d, --direction word The search direction, either forward or backward.
-e, --evaluate Convert all tags (LABEL, UUID, PARTUUID or PARTLABEL) to the corresponding device names.
-F, --tab-file path Search in an alternative file. If used with --fstab, --mtab or --kernel, then it overrides the default paths. If specified more than once, then tree-like output is disabled (see the --list option).
-f, --first-only Print the first matching filesystem only.
-i, --invert Invert the sense of matching.
-k, --kernel Search in /proc/self/mountinfo. The output is in the tree-like format. This is the default. The output contains only mount options maintained by kernel (see also --mtab).
-l, --list Use the list output format. This output format is automatically enabled if the output is restricted by the -t, -O, -S or -T option and the option --submounts is not used or if more that one source file (the option -F) is specified.
-M, --mountpoint path Explicitly define the mountpoint file or directory. See also --target.
-m, --mtab Search in /etc/mtab. The output is in the list format by default (see --tree). The output may include user space mount options.
-N, --task tid Use alternative namespace /proc/<tid>/mountinfo rather than the default /proc/self/mountinfo. If the option is specified more than once, then tree-like output is disabled (see the --list option). See also the unshare(1) command.
-O, --options list Limit the set of printed filesystems. More than one option may be specified in a comma-separated list. The -t and -O options are cumulative in effect. It is different from -t in that each option is matched exactly; a leading no at the beginning does not have global meaning. The "no" can used for individual items in the list. The "no" prefix interpretation can be disabled by "+" prefix.
-o, --output list Define output columns. See the --help output to get a list of the currently supported columns. The TARGET column contains tree formatting if the --list or --raw options are not specified.
The default list of columns may be extended if list is specified in the format +list (e.g., findmnt -o +PROPAGATION).
--output-all Output almost all available columns. The columns that require --poll are not included.
-P, --pairs Produce output in the form of key="value" pairs. All potentially unsafe value characters are hex-escaped (\x<code>). The key (variable name) will be modified to contain only characters allowed for a shell variable identifiers, for example, FS_OPTIONS and USE_PCT instead of FS-OPTIONS and USE%.
-p, --poll[=list] Monitor changes in the /proc/self/mountinfo file. Supported actions are: mount, umount, remount and move. More than one action may be specified in a comma-separated list. All actions are monitored by default.
The time for which --poll will block can be restricted with the --timeout or --first-only options.
The standard columns always use the new version of the information from the mountinfo file, except the umount action which is based on the original information cached by findmnt. The poll mode allows using extra columns:
ACTION mount, umount, move or remount action name; this column is enabled by default
OLD-TARGET available for umount and move actions
OLD-OPTIONS available for umount and remount actions
--pseudo Print only pseudo filesystems.
--shadow Print only filesystems over-mounted by another filesystem.
-R, --submounts Print recursively all submounts for the selected filesystems. The restrictions defined by options -t, -O, -S, -T and --direction are not applied to submounts. All submounts are always printed in tree-like order. The option enables the tree-like output format by default. This option has no effect for --mtab or --fstab.
-r, --raw Use raw output format. All potentially unsafe characters are hex-escaped (\x<code>).
--real Print only real filesystems.
-S, --source spec Explicitly define the mount source. Supported specifications are device, maj:min, LABEL=label, UUID=uuid, PARTLABEL=label and PARTUUID=uuid.
-s, --fstab Search in /etc/fstab. The output is in the list format (see --list).
-T, --target path Define the mount target. If path is not a mountpoint file or directory, then findmnt checks the path elements in reverse order to get the mountpoint (this feature is supported only when searching in kernel files and unsupported for --fstab). It’s recommended to use the option --mountpoint when checks of path elements are unwanted and path is a strictly specified mountpoint.
-t, --types list Limit the set of printed filesystems. More than one type may be specified in a comma-separated list. The list of filesystem types can be prefixed with no to specify the filesystem types on which no action should be taken. For more details see mount(8).
--tree Enable tree-like output if possible. The options is silently ignored for tables where is missing child-parent relation (e.g., fstab).
--shadowed Print only filesystems over-mounted by another filesystem.
-U, --uniq Ignore filesystems with duplicate mount targets, thus effectively skipping over-mounted mount points.
-u, --notruncate Do not truncate text in columns. The default is to not truncate the TARGET, SOURCE, UUID, LABEL, PARTUUID, PARTLABEL columns. This option disables text truncation also in all other columns.
-v, --nofsroot Do not print a [/dir] in the SOURCE column for bind mounts or btrfs subvolumes.
-w, --timeout milliseconds Specify an upper limit on the time for which --poll will block, in milliseconds.
-x, --verify Check mount table content. The default is to verify /etc/fstab parsability and usability. It’s possible to use this option also with --tab-file. It’s possible to specify source (device) or target (mountpoint) to filter mount table. The option --verbose forces findmnt to print more details.
--verbose Force findmnt to print more information (--verify only for now).
--vfs-all When used with VFS-OPTIONS column, print all VFS (fs-independent) flags. This option is designed for auditing purposes to list also default VFS kernel mount options which are normally not listed.
LIBMOUNT_FSTAB=<path> overrides the default location of the fstab file
LIBMOUNT_MTAB=<path> overrides the default location of the mtab file
LIBSMARTCOLS_DEBUG=all enables libsmartcols debug output
findmnt --fstab -t nfs Prints all NFS filesystems defined in /etc/fstab.
findmnt --fstab /mnt/foo Prints all /etc/fstab filesystems where the mountpoint directory is /mnt/foo. It also prints bind mounts where /mnt/foo is a source.
findmnt --fstab --target /mnt/foo Prints all /etc/fstab filesystems where the mountpoint directory is /mnt/foo.
findmnt --fstab --evaluate Prints all /etc/fstab filesystems and converts LABEL= and UUID= tags to the real device names.
findmnt -n --raw --evaluate --output=target LABEL=/boot Prints only the mountpoint where the filesystem with label "/boot" is mounted.
findmnt --poll --mountpoint /mnt/foo Monitors mount, unmount, remount and move on /mnt/foo.
findmnt --poll=umount --first-only --mountpoint /mnt/foo Waits for /mnt/foo unmount.
findmnt --poll=remount -t ext3 -O ro Monitors remounts to read-only mode on all ext3 filesystems.
fstab(5), mount(8)
The findmnt command is part of the util-linux package which can be downloaded from Linux Kernel Archive <https://www.kernel.org/pub/linux/utils/util-linux/>.
WP(1)                        General Commands Manual                       WP(1)
BITWISE(1)                        User Commands                       BITWISE(1)
bitwise - Terminal based bit manipulator in ncurses
bitwise [OPTION...] [expression]
[expression] mathematical expression
-i, --interactive Load interactive mode (default if no input)
-w, --width[b|w|l|d] Set bit width (default: l)
-v, --version Output version information and exit
-s, --si Output sizes according to SI standard. (default: IEC standard)
--no-color Start without color support
Written by Ramon Fried
The full documentation for bitwise can be found at https://github.com/mellowcandle/bitwise
DKMS(8)                      System Manager's Manual                     DKMS(8)
dkms - Dynamic Kernel Module Support
dkms [action] [options] [module/module-version] [/path/to/source-tree] [/path/to/tarball.tar] [/path/to/driver.rpm]
dkms is a framework which allows kernel modules to be dynamically built for each kernel on your system in a simplified and organized fashion.
add [module/module-version] [/path/to/source-tree] [/path/to/tarball.tar]
Adds a module/module-version combination to the tree for builds and installs.  If module/module-version, -m module/module-version, or -m module -v version are passed as options, this command requires source in /usr/src/<module>-<module-version>/ as well as a properly formatted dkms.conf file. If /path/to/source-tree is passed as an option, and source-tree contains a dkms.conf file, it will copy /path/to/source-tree to /usr/src/module-module-version.  If /path/to/tarball.tar is passed, this command behaves like the ldtarball command.
remove [module/module-version] [-k kernel/arch] [--all]
Removes a module/version or module/version/kernel/arch combination from the tree. If the module is currently installed, it first uninstalls it and if applicable, will replace it with its original_module. Use the --all option in order to remove all instances for every kernel at once.
build [module/module-version] [-k kernel/arch]
Builds the specified module/version combo for the specified kernel/arch. If the -k option is not specified it builds for the currently running kernel and arch. All builds occur in the directory /var/lib/dkms/<module>/<module-version>/build/.  If the module/module-version combo has not been added, dkms will try to add it, and in that case build can take the same arguments that add can.
unbuild [module/module-version] [-k kernel/arch] [--all]
Undoes the build for a module/version or module/version/kernel/arch combination from the tree. If the module is currently installed, it first uninstalls it and if applicable, will replace it with its original_module. Finally all binary kernel modules are removed. Use the --all option in order to remove all instances for every kernel at once.
install [module/module-version] [-k kernel/arch] [/path/to/driver.rpm]
Installs a built module/version combo onto the kernel it was built for. If the kernel option is not specified it assumes the currently running kernel.  If the module has not been built, dkms will try to build it.  If the module has not been added, dkms will try to add it. In both cases, the install command can then take the same arguments as the build or add commands.  If you pass a .rpm file, dkms will try to install that file with rpm -Uvh , and it will perform an autoinstall action to be sure that everything is built for your kernel if the RPM installed successfully.
uninstall [module/module-version] [-k kernel/arch] [--all]
Uninstalls an installed module/module-version combo from the kernel/arch passed in the -k option, or the current kernel if the -k option was not passed. Use the --all option in order to uninstall all instances for every kernel at once.  After uninstall completion, the driver will be left in the built state.  To completely remove a driver, the remove action should be utilized.
match [--templatekernel kernel/arch] [-k kernel/arch]
Match installs modules onto the specified kernel by looking at the configuration of the specified templatekernel.  Every module that is installed on the templatekernel within dkms is then installed on that specified kernel.
mktarball [module/module-version] [-k kernel/arch] [--archive /path/to/tarball.tar] [--source-only] [--binaries- only]
Creates a tarball archive for the specified module/version of all files in the DKMS tree for that module/version combination. This includes the source and any built modules for kernels in the tree (as specified).  Otherwise, you can specify a singular kernel to archive only, or multiple kernels to archive (-k kernel1/arch1 -k kernel2/arch2). Optionally, you can use --archive to specify the file that you would like to save this tarball to. You can also specify --binaries-only if you want the resultant tarball not to include the module source. Likewise, --source-only can be used to specify that no prebuilt binaries should be included in the tarball.  In general, mktarball is great for systems management purposes as you can build your driver on just one system and then use ldtarball on all of your other systems to get the same built modules loaded without having to wait for anything to compile.
ldtarball [/path/to/tarball.tar] [--force]
This takes a tarball made from the mktarball command and loads it into your DKMS tree. This will leave any newly added modules in the built state and dkms install should then be called to install any of them. If files already exist where ldtarball is attempting to place them, it will warn and not copy over them. The --force option should be used to override this.
status [module/module-version] [-k kernel/arch]
Returns the current status of modules, versions and kernels within the tree as well as whether they have been added, built or installed. Status can be shown for just a certain module, a certain kernel, a module/version combination or a module/version/kernel combination.
Attempt to install the latest revision of all modules that have been installed for other kernel revisions.  dkms_autoinstaller is a stub that uses this action to perform its work.
-m <module>/<module-version> The name of the module and module version you want to operate on. The -m part of this option is optional, and can be omitted in virtually all circumstances.
-v <module-version> The version of the module to execute the specified action upon. This option only has to be specified if you pass a -m option without a <module-version> component of its own.
-k <kernel-version>/<arch> The kernel and arch to perform the action upon. You can specify multiple kernel version/arch pairs on the command line by repeating the -k argument with a different kernel version and arch.  However, not all actions support multiple kernel versions (it will error out in this case).  The arch part can be omitted, and DKMS will assume you want it to be the arch of the currently running system.
-a, --arch The system architecture to perform the action upon. It is optional if you pass it as part of the -k option. If not specified, it assumes the arch of the currently running system (`uname -m`). You can specify multiple arch parameters on the same command line by repeating the -a argument with a different arch name. When multiple architectures are specified, there must be a 1:1 relationship between -k arguments to -a arguments. DKMS will then assume the first -a argument aligns with the first -k kernel and so on for the second, third, etc.
For example, if you were to specify: -k kernel1 -k kernel2 -a i386 -k kernel3 -a i686 -a x86_64, DKMS would process this as: kernel1-i386, kernel2-i686, kernel3-x86_64.
-V, --version Prints the currently installed version of dkms and exits.
-c <dkms.conf-location> The location of the dkms.conf file. This is needed for the add action and if not specified, it is assumed to be located in /usr/src/<module>-<module-version>/.  See below for more information on the format of dkms.conf.
--config <kernel-.config-location> During a build this option is used to specify an alternate location for the kernel .config file which was used to compile that kernel. Normally, dkms uses the Red Hat standard location and config filenames located in /usr/src/linux-<kernel>/configs/.  If the config for the kernel that you are building a module for is not located here or does not have the expected name in this location, you will need to tell dkms where the necessary .config can be found so that your kernel can be properly prepared for the module build.
--archive <tarball-location> This option is used during a ldtarball action to specify the location of the tarball you wish to load into your DKMS tree. You only have to specify the --archive part of this option if <tarball-location> does not already exist as a file.
--templatekernel <kernel-version> This option is required for the action: match.  Match will look at the templatekernel specified and install all of the same module/version combinations on the other kernel.
--force This option can be used in conjunction with ldtarball to force copying over of extant files.
--binaries-only This option can be used in conjunction with mktarball in order to create a DKMS tarball which does not contain the source for the module within it. This can be helpful in reducing the size of the tarball if you know that the system which this tarball will be loaded upon already has the source installed. In order to load a tarball made as binaries-only you must have the module source in that systems DKMS tree. If you do not, DKMS will refuse to load a binaries-only tarball.
--source-only This option can be used in conjunction with mktarball but do not want the tarball you create to have any prebuilt modules within it, passing this option will keep its internal DKMS tarball from containing any prebuilt modules.
--all  This option can be used to automatically specify all relevant kernels/arches for a module/module-version. This can be used for things like remove, unbuild and uninstall. This saves the trouble of having to actually specify -k kernel1 -a arch1 -k kernel2 -a arch2 for every kernel you have built your module for.
--no-depmod This option prevents DKMS from running the depmod command during install and uninstall which will avoid (re)calculating module dependencies and thereby save time.
--modprobe-on-install This option executes modprobe on the modules upon successful installation.
--kernelsourcedir <kernel-source-directory-location> Using this option you can specify the location of your kernel source directory. Most likely you will not need to set this if your kernel source is accessible via /usr/lib/modules/$kernel_version/build.
--directive <"cli-directive=cli-value"> Using this option, you can specify additional directives from the command line. The --directive option can be used multiple times on the same command-line to specify multiple additional command line directives.
--rpm_safe_upgrade This flag should be used when packaging DKMS enabled modules in RPMs. It should be specified during both the add and remove actions in the RPM spec to ensure that DKMS and RPM behave correctly in all scenarios when upgrading between various versions of a dkms enabled module RPM package.
--dkmstree path/to/place Provides a destination tree for building and installing modules to. Useful in cases that you don't want to contaminate a system when using solely for building.
--sourcetree path/to/place Provides a location to build a DKMS package from. Useful for systems that you may not have root access, but would still like to be able to build DKMS packages.
--installtree path/to/place Provides a location to place modules when a dkms install command is issued.
--dkmsframework path/to/file A supplemental configuration file to the system-wide dkms framework, typically located in /etc/dkms/framework.conf. All option that are normally provided on a command line can be provided in this file.
-j number Run no more than number jobs in parallel; see the -j option of make(1).  Defaults to the number of CPUs in the system, detected by nproc(1).  Specify 0 to impose no limit on the number of parallel jobs.
During the first install of a module for a <kernelversion>, dkms will search /usr/lib/modules/<kernelversion> for a pre-existing module of the same name. If one is found, it will automatically be saved as an "original_module" so that if the newer module is later removed, dkms will put the original module back in its place. Currently, DKMS searches for these original modules with first preference going to modules located in /usr/lib/modules/<kernelversion>/updates/ followed by $DEST_MODULE_LOCATION (as specified in dkms.conf ). If one cannot be found in either location, a find will be used to locate one for that kernel.  If none are found, then during a later uninstall, your kernel will not have that module replaced.
If more than one is found, then the first one located (by preference indicated above) will be considered the "original_module". As well, all copies of the same-named module will be removed from your kernel tree and placed into /var/lib/dkms/<module>/original_module/$kernelver/collisions so that they can be *manually* accessible later. DKMS will never actually do anything with the modules found underneath the /collisions directory, and they will be stored there until you manually delete them.
DKMS.CONF When performing an add , a proper dkms.conf file must be found. A properly formatted conf file is essential for communicating to dkms how and where the module should be installed. While not all the directives are required, providing as many as possible helps to limit any ambiguity. Note that the dkms.conf is really only a shell-script of variable definitions which are then sourced in by the dkms executable (of the format, DIRECTIVE="directive text goes here"). As well, the directives are case-sensitive and should be given in ALL CAPS.
It is important to understand that many of the DKMS directives are arrays whose index values are tied together. These array associations can be considered families, and there are currently three such families of directive arrays. MAKE[#] and MAKE_MATCH[#] make up one family. PATCH[#] and PATCH_MATCH[#] make up the second family. The third and largest family consists of BUILT_MODULE_NAME[#], BUILT_MODULE_LOCATION[#], DEST_MODULE_NAME[#], DEST_MODULE_LOCATION[#] and STRIP[#]. When indexing these arrays when creating your dkms.conf, each family should start at index value 0.
MAKE[#]= The MAKE directive array tells DKMS which make command should be used for building your module. The default make command should be put into MAKE[0].  Other entries in the MAKE array will only be used if their corresponding entry in MAKE_MATCH[#] matches, as a regular expression (using egrep), the kernel that the module is being built for.  Note that if no value is placed in MAKE_MATCH[#] for any MAKE[#] where # > 0, then that MAKE directive is ignored. MAKE_MATCH[0] is optional and if it is populated, it will be used to determine if MAKE[0] should be used to build the module for that kernel. If multiple MAKE_MATCH directives match against the kernel being built for, the last matching MAKE[#] will be used to build your module. If no MAKE directive is specified or if no MAKE_MATCH matches the kernel being built for, DKMS will attempt to use a generic MAKE command to build your module.
KERNELRELEASE will be automatically appended to MAKE[#]. If you want to suppress this behavior, you can quote the make command: 'make'.
MAKE_MATCH[#]= See the above entry on MAKE[#] directives. This array should be populated with regular expressions which, when matched against the kernel being built for, will tell DKMS to use the corresponding make command in the MAKE[#] directive array to build your module.
BUILT_MODULE_NAME[#]= This directive gives the name of the module just after it is built. If your DKMS module package contains more than one module to install, this is a required directive for all of the modules. This directive should explicitly not contain any trailing ".o" or ".ko".  Note that for each module within a dkms package, the numeric value of # must be the same for each of BUILT_MODULE_NAME, BUILT_MODULE_LOCATION, DEST_MODULE_NAME and DEST_MODULE_LOCATION and that the numbering should start at 0 (eg. BUILT_MODULE_NAME[0]="qla2200" BUILT_MODULE_NAME[1]="qla2300").
BUILT_MODULE_LOCATION[#]= This directive tells DKMS where to find your built module after it has been built. This pathname should be given relative to the root directory of your source files (where your dkms.conf file can be found). If unset, DKMS expects to find your BUILT_MODULE_NAME[#] in the root directory of your source files.  Note that for each module within a dkms package, the numeric value of # must be the same for each of BUILT_MODULE_NAME, BUILT_MODULE_LOCATION, DEST_MODULE_NAME and DEST_MODULE_LOCATION and that the numbering should start at 0 (eg. BUILT_MODULE_LOCATION[0]="some/dir/" BUILT_MODULE_LOCATION[1]="other/dir/").
DEST_MODULE_NAME[#]= This directive can be used to specify the name of the module as it should be installed. This will rename the module from BUILT_MODULE_NAME[#] to DEST_MODULE_NAME[#].  This directive should explicitly not contain any trailing ".o" or ".ko". If unset, it is assumed to be the same value as BUILT_MODULE_NAME[#]. Note that for each module within a dkms package, the numeric value of # must be the same for each of BUILT_MODULE_NAME, BUILT_MODULE_LOCATION, DEST_MODULE_NAME and DEST_MODULE_LOCATION and that the numbering should start at 0 (eg. DEST_MODULE_NAME[0]="qla2200_6x" DEST_MODULE_NAME[1]="qla2300_6x").
DEST_MODULE_LOCATION[#]= This directive specifies the destination where a module should be installed to, once compiled. It also is used for finding original_modules. This is a required directive, except as noted below. This directive must start with the text "/kernel" which is in reference to /usr/lib/modules/<kernelversion>/kernel.  Note that for each module within a dkms package, the numeric value of # must be the same for each of BUILT_MODULE_NAME, BUILT_MODULE_LOCATION, DEST_MODULE_NAME and DEST_MODULE_LOCATION and that the numbering should start at 0 (eg. DEST_MODULE_LOCATION[0]="/kernel/drivers/something/" DEST_MODULE_LOCATION[1]="/kernel/drivers/other/").
DEST_MODULE_LOCATION is ignored on Fedora and Red Hat Enterprise Linux, Novell SuSE Linux Enterprise Server 10 and higher, Novell SuSE Linux 10.0 and higher, and Ubuntu. Instead, the proper distribution-specific directory is used.
STRIP[#]= By default strip is considered to be "yes". If set to "no", DKMS will not run strip -g against your built module to remove debug symbols from it.  STRIP[0] is used as the default for any unset entries in the STRIP array.
PACKAGE_NAME= This directive is used to give the name associated with the entire package of modules. This is the same name that is used with the -m option when building, adding, etc. and may not necessarily be the same as the MODULE_NAME. This directive must be present in every dkms.conf.
PACKAGE_VERSION= This directive is used to give the version associated with the entire package of modules being installed within that dkms package. This directive must be present in every dkms.conf.
CLEAN= CLEAN specifies the make clean command to be used to clean up both before and after building the module. If unset, it is assumed to be "make clean".
OBSOLETE_BY= This directive allows you to specify a kernel version that obsoletes the necessity for this particular DKMS module. This can be specified as a particular upstream kernel or an ABI bump of a kernel. For example, "2.6.24" would be an upstream kernel and "2.6.24-16" would represent an ABI bump for a kernel. Both are valid in this area.
Please avoid the use of OBSOLETE_BY wherever possible. It's use indicates a lack of proper module versioning using MODULE_VERSION() tags in the module source itself. It is better to fix the MODULE_VERSION() tags than use OBSOLETE_BY.  This also introduces a implicit distribution/version dependency on the package, as the value of OBSOLETE_BY is meaningful only in the context of a single distribution/version.
If you feel you must use it, please use as such in dkms.conf:
ubuntu_804="Ubuntu 8.04" if [ -x /usr/bin/lsb_release ]; then if [ "$(/usr/bin/lsb_release -sir)" == "${ubuntu_804}" ]; then OBSOLETE_BY="2.6.25" fi fi
PATCH[#]= Use the PATCH directive array to specify patches which should be applied to your source before a build occurs.  All patches are expected to be in -p1 format and are applied with the patch -p1 command.  Each directive should specify the filename of the patch to apply, and all patches must be located in the patches subdirectory of your source directory ( /usr/src/<module>-<module-version>/patches/ ). If any patch fails to apply, the build will be halted and the rejections can be inspected in /var/lib/dkms/<module>/<module-version>/build/.  If a PATCH should only be applied conditionally, the PATCH_MATCH[#] array should be used, and a corresponding regular expression should be placed in PATCH_MATCH[#] which will alert dkms to only use that PATCH[#] if the regular expression matches the kernel which the module is currently being built for.
PATCH_MATCH[#]= See the above description for PATCH[#] directives. If you only want a patch applied in certain scenarios, the PATCH_MATCH array should be utilized by giving a regular expression which matches the kernels you intend the corresponding PATCH[#] to be applied to before building that module.
AUTOINSTALL= If this directive is set to yes then the service /etc/rc.d/init.d/dkms_autoinstaller will automatically try to install this module on any kernel you boot into. See the section on dkms_autoinstaller for more information.
BUILD_DEPENDS[#]= This optional directive is an array that allows you to specify other modules as dependencies for your module. Each array element should be the PACKAGE_NAME of another module that is managed by dkms. Do not specify a version or architecture in the dependency. Note that this directive is only advisory; missing or broken dependencies cause non-fatal warnings.
BUILD_EXCLUSIVE_KERNEL= This optional directive allows you to specify a regular expression which defines the subset of kernels which DKMS is allowed to build your module for. If the kernel being built for does not match against this regular expression, the dkms build will error out. For example, if you set it as ="^2.4.*", your module would not be built for 2.6 kernels.
BUILD_EXCLUSIVE_ARCH= This optional directive functions very similarly to BUILD_EXCLUSIVE_KERNEL except that it matches against the kernel architecture. For example, if you set it to ="i.86", your module would not be built for ia32e, x86_64, amd64, s390, etc.
POST_ADD= The name of the script to be run after an add is performed. The path should be given relative to the root directory of your source.
POST_BUILD= The name of the script to be run after a build is performed. The path should be given relative to the root directory of your source.
POST_INSTALL= The name of the script to be run after an install is performed. The path should be given relative to the root directory of your source.
POST_REMOVE= The name of the script to be run after a remove is performed. The path should be given relative to the root directory of your source.
PRE_BUILD= The name of the script to be run before a build is performed. The path should be given relative to the root directory of your source.
PRE_INSTALL= The name of the script to be run before an install is performed. The path should be given relative to the root directory of your source. If the script exits with a non-zero value, the install will be aborted. This is typically used to perform a custom version comparison.
DKMS.CONF VARIABLES Within your dkms.conf file, you can use certain variables which will be replaced at run-time with their values.
$kernelver This variable can be used within a directive definition and during use, the actual kernel version in question will be substituted in its place. This is especially useful in MAKE commands when specifying which INCLUDE statements should be used when compiling your module (eg. MAKE="make all INCLUDEDIR=/usr/lib/modules/${kernelver}/build/include").
$dkms_tree See the section on /etc/dkms/framework.conf for more information. This variable represents the location of the DKMS tree on the local system. By default this is /var/lib/dkms , but this value should not be hard-coded into a dkms.conf in the event that the local user has changed it on their system.