Merge remote-tracking branch 'upstream/unstable' into unstable

.github/workflows/integration_tests.yml

@@ -3,20 +3,7 @@ on:
   [push, pull_request]
 
 jobs:
-  initialize-repository:
-    runs-on: ubuntu-latest
-    defaults:
-      run:
-        shell: bash
-
-    steps:
-      - name: Checkout repository
-        uses: actions/checkout@v4
-        with:
-          fetch-depth: 1
-
   integration-tests:
-    needs: initialize-repository
     runs-on: ubuntu-latest
 
     steps:

database/migrate_legacy_data_20220101.sh

@@ -99,7 +99,7 @@ function migrate_statistics()
   cmd_manager 'SILENT' "mv ${datadir}/statistics ${datadir}/legacy_statistics"
   if [[ "$?" != 0 ]]; then
     complain "Couldn't rename ${datadir}/statistics ${datadir}/legacy_statistics"
-    return 1 #EPERM
+    return 1 # EPERM
   fi
 }
 
@@ -161,7 +161,7 @@ function migrate_pomodoro()
   cmd_manager 'SILENT' "mv ${datadir}/pomodoro ${datadir}/legacy_pomodoro"
   if [[ "$?" != 0 ]]; then
     complain "Couldn't rename ${datadir}/pomodoro ${datadir}/legacy_pomodoro"
-    return 1 #EPERM
+    return 1 # EPERM
   fi
 }
 
@@ -216,20 +216,20 @@ function migrate_kernel_configs()
   cmd_manager 'SILENT' "cp -r ${configs_dir}/. ${datadir}/configs"
   if [[ "$?" != 0 ]]; then
     complain "Couldn't copy kernel config files from ${configs_dir} to ${datadir}/configs"
-    return 1 #EPERM
+    return 1 # EPERM
   fi
 
   # mark migrated directories to avoid duplicated data
   cmd_manager 'SILENT' "mv ${datadir}/configs/configs ${datadir}/configs/legacy_configs"
   if [[ "$?" != 0 ]]; then
     complain "Couldn't rename ${datadir}/configs/configs to ${datadir}/configs/legacy_configs"
-    return 1 #EPERM
+    return 1 # EPERM
   fi
 
   cmd_manager 'SILENT' "mv ${datadir}/configs/metadata ${datadir}/configs/legacy_metadata"
   if [[ "$?" != 0 ]]; then
     complain "Couldn't rename ${datadir}/configs/metadata to ${datadir}/configs/legacy_metadata"
-    return 1 #EPERM
+    return 1 # EPERM
   fi
 }
 

documentation/dependencies/kernel_build/arch.dependencies

@@ -0,0 +1,17 @@
+make
+base-devel
+linux-headers
+bison
+flex
+openssl
+ncurses
+pahole
+xmlto
+kmod
+inetutils
+bc
+libelf
+cpio
+perl
+tar
+xz

documentation/dependencies/kernel_build/debian.dependencies

@@ -0,0 +1,20 @@
+libncurses-dev
+gawk
+flex
+bison
+openssl
+libssl-dev
+dkms
+libelf-dev
+libudev-dev
+libpci-dev
+libiberty-dev
+autoconf
+llvm
+exuberant-ctags
+build-essential
+xmlto
+kmod
+dwarves
+clang
+lld

documentation/dependencies/kernel_build/fedora.dependencies

@@ -0,0 +1,12 @@
+qt3-devel
+libXi-devel
+diffutils
+gcc-c++
+ncurses-devel
+bison
+flex
+openssl-devel
+elfutils-libelf-devel
+openssl
+dwarves
+llvm

documentation/man/features/kw-build.rst

@@ -17,6 +17,7 @@ SYNOPSIS
 | *kw* (*b* | *build*) [(-c | \--clean)] [\--alert=(s | v | (sv | vs) | n)]
 | *kw* (*b* | *build*) [(-f | \--full-cleanup)] [\--alert=(s | v | (sv | vs) | n)]
 | *kw* (*b* | *build*) [\--cflags]
+| *kw* (*b* | *build*) [\--from-sha <SHA>]
 | *kw* (*b* | *build*) [\--verbose]
 
 DESCRIPTION
@@ -40,15 +41,15 @@ OPTIONS
 
 -n, \--menu:
   The menu option invokes the kernel menuconfig. Notice that the default menu
-  config can be changed in the **kworkflow.config** file by setting a different
+  config can be changed in the **build.config** file by setting a different
   option in *menu_config*. If the user is working in a *cross-compile*
   environment, it is recommended to use this option to avoid messing with the
   config file manually.
 
 -d, \--doc:
   The doc option provides a mechanism for building the kernel-doc; by default,
   it will build htmldocs. Users can change the default documentation output by
-  changing the parameter *doc_type* in the **kworkflow.config** file.
+  changing the parameter *doc_type* in the **build.config** file.
 
 -S, \--cpu-scaling:
   The cpu-scaling option lets the user set whichever CPU usage they want from
@@ -61,12 +62,12 @@ OPTIONS
 
 -w, \--warnings (1 | 2 | 3 | 12 | 13 | 23 | 123):
   This can be used to enable compilation warnings accordingly. You can set the
-  default log level via `build.config` file under the option `warning_level`.
+  default log level via **build.config** file under the option `warning_level`.
   Please check the kernel's ``make help`` for more info.
 
--s, \--save-log-to=path:
+-s, \--save-log-to path:
   This option will save the full compilation log with the enabled warnings to
-  the specified path. You can set the default log path in the `build.config`
+  the specified path. You can set the default log path in the **build.config**
   file via `log_path` option.
 
 \--llvm:
@@ -102,10 +103,15 @@ OPTIONS
     | **sv** or **vs** enables both.
     | **n** (or any other option) disables notifications (this is the default).
 
+\--from-sha:
+  Build every commit after <SHA> to branch head. Useful for testing if all patches in
+  patchset compile.
+
 EXAMPLES
 ========
-For these examples, we suppose the fields in your **kworkflow.config** file are
-already configured.
+For these examples, we assume that the relevant fields in your configuration 
+files (located by default in **.kw/**) have already been setup. We recommend
+the use of ``kw config`` for managing your local and global configurations.
 
 For building and installing a new module version based on the current kernel
 version, you can use::
@@ -141,7 +147,7 @@ using::
 Sometimes we have a lot of error message that does not fit in the terminal
 buffer; in these cases it is helpful to save all logs in a file::
 
-  kw b --warnings 123 --save-log-to=ALL_WARNINGS.log
+  kw b --warnings 123 --save-log-to ALL_WARNINGS.log
 
 If you want to use llvm::
 
@@ -158,3 +164,11 @@ If you want to reset the kernel tree to its default, `all config and script outp
 If you want to use cflags::
 
   kw b --cflags "-O3 -pipe -march=native"
+
+If you want to build every commit after HEAD~2 to HEAD::
+
+  kw b --from-sha HEAD~2
+
+If you want to build every commit after ee3b5 to HEAD::
+
+  kw b --from-sha ee3b5

documentation/man/features/kw-codestyle.rst

@@ -29,8 +29,9 @@ OPTIONS
 
 EXAMPLES
 ========
-For these examples, we suppose the fields in your **kworkflow.config** file are
-already configured.
+For these examples, we assume that the relevant fields in your configuration 
+files (located by default in **.kw/**) have already been setup. We recommend
+the use of ``kw config`` for managing your local and global configurations.
 
 For checking the code style::
 

documentation/man/features/kw-deploy.rst

@@ -31,22 +31,23 @@ executed:
 
 You can specify the deploy target via command line by using the flag
 ``--remote <remote>:<port>`` (e.g., ``--remote 172.16.254.1:22``); however, if
-you do this frequently you will probably prefer to add this information to your
-local **kworkflow.config**. See the example below::
+you plan on deploying to the same remote frequently can benefit from using the
+``kw remote`` feature to save the SSH information in a configuration file
+used by kw, for example::
 
-  default_deploy_target=remote
-  ssh_user=root
-  ssh_ip=172.16.254.1
-  ssh_port=22
+  kw remote --add origin [email protected]
+
+For more information, check ``kw remote --help``
 
 If you want to install a new kernel version in your host machine, you can use
 the flag ``--local``; you will need to use your root password.
 
-Another typical operation when deploying a new kernel to a test machine, it is
-the reboot after the update. You can explicitly say it for **kw** by adding the
-flag ``--reboot``, add this to the **kworkflow.config** with::
+Another typical operation when deploying a new kernel to a test machine is
+rebooting after the update. You can add the ``--reboot`` flag to a command to
+explicitly make **kw** reboot the machine afterwards, or you can set this to 
+always happen by modifying ``reboot_after_deploy`` flag in **deploy.config** with::
 
-  reboot_after_deploy=yes
+  kw config deploy.reboot_after_deploy yes
 
 This can be used with conjunction the :ref:`build<build-doc>` command by
 invoking ``kw bd``.
@@ -117,8 +118,9 @@ OPTIONS
 
 EXAMPLES
 ========
-For these examples, we suppose the fields in your **kworkflow.config** file are
-already configured.
+For these examples, we assume that the relevant fields in your configuration 
+files (located by default in **.kw/**) have already been setup. We recommend
+the use of ``kw config`` for managing your local and global configurations.
 
 First, if you are working in a specific kernel module, and if you want to
 install your recent changes in your local machine you can use::

documentation/man/features/kw-drm.rst

@@ -26,8 +26,8 @@ OPTIONS
 \--local, \--remote [<remote>:<port>]:
   This option specifies the target device for the drm action, it can be a
   remote or local machine. If these options are not explicitly passed via
-  command line, **kw** going to take the target set in the variable
-  *default_deploy_target* (**kworkflow.config**) for identifying the target.
+  command line, **kw** is going to take the target set in the variable
+  *default_deploy_target* (**deploy.config**) for identifying the target.
   It is important to highlight that the drm feature **does not support VM**.
 
 -lm, \--load-module=<module>[:<param1>,...][;<module>:...]:
@@ -55,8 +55,25 @@ OPTIONS
   systemctl operation but users can change this behavior by set *gui_off* with
   a specific command in the **kworkflow.config** file with the specific command.
 
+\--gui-on-after-reboot:
+  This option sets the GUI to turn on automatically after the next reboot. By default,
+  it uses systemctl operation; however, users are free to add any specific
+  command for activating their preferred GUI in the variable *gui_on_after_reboot*
+  in the **kworkflow.config** file.
+  Note: This change will take effect only after the system is rebooted. To enable
+  the GUI immediately, use the --gui-on option.
+
+\--gui-off-after-reboot:
+  This option sets the GUI to turn off automatically after the next reboot. By default,
+  it uses systemctl operation; however, users are free to add any specific
+  command for deactivating their GUI in the variable *gui_off_after_reboot*
+  in the **kworkflow.config** file.
+  Note: This change will take effect only after the system is rebooted. To disable
+  the GUI immediately, use the --gui-off option.
+
 \--conn-available:
-  Show all connectors available in the target machine.
+  Show all connectors available in the target machine. The ones marked with '*'
+  are enabled.
 
 \--modes:
   Show all available modes per card.
@@ -68,8 +85,9 @@ OPTIONS
 
 EXAMPLES
 ========
-For these examples, we suppose the fields in your **kworkflow.config** file are
-already configured.
+For these examples, we assume that the relevant fields in your configuration 
+files (located by default in **.kw/**) have already been setup. We recommend
+the use of ``kw config`` for managing your local and global configurations.
 
 If you are working with DRM drivers, you can take advantage of load and unload
 commands combined with GUI control commands. For example::

documentation/man/features/kw-explore.rst

@@ -7,7 +7,7 @@ kw-explore - Explore folder
 SYNOPSIS
 ========
 *kw* (*e* | *explore*) [(-l | \--log) | (-g | \--grep) | (-a | \--all) | \--verbose]
-                       [(-c | \--only-source) | (-H | \--only-header)] <expr>
+                       [(-c | \--only-source) | (-H | \--only-header)] [(-C[<num>] | \--show-context[=<num>])] <expr>
                        [-p] [<dir> | <file>]
 
 DESCRIPTION
@@ -45,5 +45,23 @@ OPTIONS
 -H | \--only-header:
   With this option, it is possible to show only the results from the header.
 
+-C[<num>] | \--show-context[=<num>]:
+  Show <num> lines of additional context above and below the matched line.
+  If <num> is not specified, the default value of 3 will be used.
+
 \--verbose:
   Verbose mode allows the user to see the commands executed under the hood.
+
+EXAMPLES
+========
+To show matched line with context using long-form flag::
+
+  kw explore --show-context=5 search_string
+
+To show matched line with context using short flag::
+
+  kw explore -C5 search_string
+
+Search through all tracked and untracked files, default value of 3 will be used for context::
+
+  kw explore -C --all search_string

documentation/man/features/kw-init.rst

@@ -11,9 +11,9 @@ SYNOPSIS
 
 DESCRIPTION
 ===========
-This command creates a **.kw** folder containing a **kworkflow.config** file in
+This command creates a **.kw** folder containing default configuration files in
 the current kernel directory. The primary reason for running ``kw init`` is to
-pick up a freshly created config file.
+pick up freshly created config files.
 
 OPTIONS
 =======
@@ -25,7 +25,7 @@ OPTIONS
   creating the local config file.
 
 \--arch <arch>:
-  Set the variable `arch` from the newly created **kworkflow.config** file.
+  Set the variable `arch` from the newly created **build.config** file.
   Before actually changing it, this option checks if *<arch>* is a valid
   architecture found in the **arch** folder from the kernel directory.
 
@@ -34,7 +34,7 @@ OPTIONS
   and *<port>*, respectively.
 
 \--target <target>:
-  Set the variable `default_deploy_target` from **kworkflow.config** to
+  Set the variable `default_deploy_target` from **deploy.config** to
   *<target>*, which can be local or remote.
 
 \--verbose:
@@ -45,17 +45,19 @@ EXAMPLES
 For these examples, we suppose that the kernel directory is your current
 directory.
 
-For initializing a **kworkflow.config** with `arch` set to arm, use::
+For initializing a **build.config** with `arch` set to arm, use::
 
   kw init --arch arm
 
-To initialize **kworkflow.config** with `arch` set to x86, `ssh_user` set to
-john, `ssh_ip` set to localhost, and `ssh_port` set to 2222, run::
+To initialize **build.config** with `arch` set to x86 and a **kworkflow.config** 
+with `ssh_user` set to john, `ssh_ip` set to localhost, and `ssh_port` 
+set to 2222, run::
 
   kw init --arch x86 --remote john@localhost:2222
 
-For initializing a **kworkflow.config** with `arch` set to arm64, `target` set to
-remote, `ssh_user` mary, `ssh_ip` localhost, and `ssh_port` 1234, run::
+For initializing a **build.config** with `arch` set to arm64, a **deploy.config**
+with `target` set to remote and a **kworkflow.config** with `ssh_user` mary, 
+`ssh_ip` localhost, and `ssh_port` 1234, run::
 
   kw init --arch arm64 --remote mary@localhost:1234 --target remote