Re: customize-linux not working as expected

[Maxim Cournoyer]

Hi,

"dabbede@gmail.com" <dabbede@gmail.com> writes:

> Dear community,
>
> I would like to customize the configuration of my linux kernel, in
> particular of a xenomai-patched one.
> In the past days I've followed the route of using the procedure
> make-linux-libre*, in particular using the
> key  #:extra-options to append my customizations to
> %default-extra-linux-options. In that case I did
> not encounter any suspect behavior (except for the fact that
> %default-extra-linux-options must be
> appended after my list, and not the opposite, in order to have my
> settings in place).
>
> Today I've decided to give a try to the new procedure
> "customize-linux". Here is the snippet:
> ----------------------------------------------------------------------------------------------------
> define-public linux-xenomai
>  (let ((father ((@@ (gnu packages linux) customize-linux)
>             #:name "linux-xenomai"
>             #:linux linux-libre-5.4
>             #:defconfig "x86_64_defconfig"
>             #:configs
>             '("CONFIG_LOCALVERSION=\"-xenomai3.2.2\""
>               ;; Xenomai specific tweaks
>               "# CONFIG_SCHED_MC_PRIO is not set"
>               "# CONFIG_CPU_FREQ is not set"
>               "# CONFIG_ACPI_PROCESSOR is not set"
>               "# CONFIG_CPU_IDLE is not set"
>               "# CONFIG_APM is not set"
>               "# CONFIG_INTEL_IDLE is not set"
>               "# CONFIG_INPUT_PCSPKR is not set"
>               "# CONFIG_COMPACTION is not set"
>               "# CONFIG_MIGRATION is not set"
>               ;; PCP customization
>               "CONFIG_XENO_DRIVERS_NET=y"
>               "CONFIG_XENO_DRIVERS_NET_DRV_E1000=m"
>               "CONFIG_XENO_DRIVERS_NET_DRV_E1000E=m"
>               "CONFIG_XENO_DRIVERS_NET_DRV_IGB=m"
>               "CONFIG_NTFS_FS=m"
>               "CONFIG_NTFS_RW=y"
>               "CONFIG_CIFS=m"
>               "CONFIG_CIFS_XATTR=y"
>               "CONFIG_CONSOLE_LOGLEVEL_DEFAULT=4")))
>        (ipipepatch (ipipe-x86-patch "5.4.228-x86-12"
> "05l092vfswqlwyis0m6x5wa5hxwlmv7jwjpnjrbjav0b5ibv0xnr")))
>  (package
>    (inherit father)
>    (name "linux-xenomai")
>    (version "5.4.228")
>    (arguments
>      (substitute-keyword-arguments (package-arguments father)
>           ((#:phases phases)
>            #~(modify-phases #$phases
>              (add-after 'unpack 'unpack-extra-sources
>                 (lambda _
>                   (begin
>                    (copy-recursively #+ipipepatch "ipipe.patch")
>                    (copy-recursively #+xenomai-origin "xeno-source.tar.bz2")
>                    (invoke "tar" "-xjf" "xeno-source.tar.bz2")
>                    (invoke "bash" (string-append "xenomai-v"
> #$xenomai-version "/scripts/prepare-kernel.sh") "--ipipe=ipipe.patch"
> "--arch=x86_64"))))))))
>    (synopsis "Linux kernel with Xenomai Cobalt co-kernel")
>    (description
>     "Xenomai is a Free Software project in which engineers from a wide
>      background collaborate to build a robust and resource-efficient
>      real-time core for Linux following the dual kernel approach, for
>      applications with stringent latency requirements.")
>    (home-page "http://xenomai.org/";))))
> ----------------------------------------------------------------------------------------------------
>
> Unfortunately, some of my custom configs are in contrast to the
> default one (and they have to be that
> way for xenomai to work), and this leads the build process to stop at
> "verify-config".
> Here is the output to the terminal:
> ----------------------------------------------------------------------------------------------------
> error: in phase 'configure': uncaught exception:
> misc-error #f "~A ~S" ("Mismatching configurations in .config and
> arch/x86/configs/guix_defconfig" (("CONFIG_JUMP_LABEL" (#f "y"))
> ("CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE" (#f "y"))
> ("CONFIG_CPU_FREQ_GOV_PERFORMANCE" (#f "y"))
> ("CONFIG_CPU_FREQ_GOV_ONDEMAND" (#f "y")) ("CONFIG_X86_ACPI_CPUFREQ"
> (#f "y")) ("CONFIG_NF_CONNTRACK_IPV4" (#f "y"))
> ("CONFIG_IP_NF_TARGET_MASQUERADE" ("m" "y"))
> ("CONFIG_NF_CONNTRACK_IPV6" (#f "y")) ("CONFIG_SND_MIXER_OSS" (#f
> "y")) ("CONFIG_SND_PCM_OSS" (#f "y")) ("CONFIG_SND_SEQUENCER_OSS" (#f
> "y")) ("CONFIG_TIMER_STATS" (#f "y")) ("CONFIG_DEBUG_STACKOVERFLOW"
> (#f "y")) ("CONFIG_XENO_DRIVERS_NET" ("m" "y")))) #f
> phase `configure' failed after 111.5 seconds

[...]

> ----------------------------------------------------------------------------------------------------
>
> This behaviour is strange to me, as I was expecting my #:configs to
> take priority over default ones.
>
> Am I missing something?!
> Thank you for your support!

The new customize-linux procedure ensures that the provided #:defconfig
(or default defconfig if not specified), modified by #:configs, let's
name that "guix_defconfig" generates a .config file that can be saved
back exactly into exactly the same "guix_defconfig" when calling "make
savedefconfig".

This is very strict indeed, and unless you produced the defconfig from
'make menuconfig', you'll need to pay attention to each kconfig
dependency effect.  The upside is that the defconfig you version or the
set of options you pass is fully specified.  If another option got
implicitly turned on or disabled by the one you've added in #:configs,
you'll need to add theses too to #:configs, if you want to use that
field.

Seen from that angle, #:configs appears to be best suited for options
that do not have complex kconfig dependencies; else it's best to version
your defconfig and manipulate it through 'make menuconfig' and 'make
savedefconfig'.

Hopefully that's helpful,

-- 
Thanks,
Maxim