web-dev-qa-db-ja.com

LinuxカーネルKconfigの「select」と「depends」の違いは何ですか?

カーネルKconfigファイルのselectと_depends on_の依存関係の違いは何ですか?

_config FB_CIRRUS
tristate "Cirrus Logic support"
depends on FB && (ZORRO || PCI)
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
---help---
This enables support for Cirrus Logic Gd542x/543x based boards on
Amiga: SD64, Piccolo, Picasso II/II+, Picasso IV, or EGS Spectrum.
_

上記の例では、_FB_CIRRUS_は、_FB_CFB_FILLRECT_、_FB_CFB_COPYAREA_および_FB_CFB_IMAGEBLIT_よりもFB && (ZORRO || PCI)にどのように関連していますか?

更新

_depend on_はコンパイル順に関してはあまり機能しないことに気づきました。

例えば。 AppBの正常なビルドは、最初にビルドされる静的にリンクされたLibBに依存しています。 AppBのKconfigで_depends on LibB_を設定しても、LibBが最初にビルドされることはありません。 _select LibB_を設定します。

11

_depends on_は、このオプションを構成するために、シンボルが既に確実に選択されている必要があることを示します(_=y_)。たとえば、depends on FB && (ZORRO || PCI)は、FBが選択されている必要があり、(&&)ZORROまたは(||)PCIが選択されている必要があることを意味します。 _make menuconfig_などの場合、これはオプションが表示されるかどうかを決定します。

selectはシンボルを積極的に設定します。たとえば、_select FB_CFB_FILLRECT_は_FB_CFB_FILLRECT=y_を意味します。これは、いくつかの他の構成オプションの潜在的な依存関係を満たします。カーネルのドキュメントでは、「可視」シンボル(ユーザーが選択または選択解除できる)またはそれ自体に依存関係のあるシンボルはこれらを使用しないため、これを使用しないように注意してくださいチェックされます。

参照: https://www.kernel.org/doc/Documentation/kbuild/kconfig-language.txt

17
goldilocks

dependsは、その前提条件(背後にあるブール構造)が満たされた場合にのみ、オプションがメニューに表示されることを意味します。

selectは、ユーザーがこのオプションを選択すると、selectの引数として指定されたオプションが自動的に選択されることを意味します。

3
mirabilos

私が考えたいのは次のとおりです:

  • selectdependsの「サブセット」であり、機能の依存関係が1つしかない場合に使用します。

    可能な依存関係は1つしかないため、selectはそのオプションを自動的に選択するだけで、最初に手動で依存関係を明示的に選択する手間を省きます。

    この自動化は、依存関係が1つしかないというサブセット制限から得られるものです。

  • dependsはより一般的で、機能が複数の実装を持つインターフェースに依存する場合に機能します。

    たとえば、4.15では、クラシックと拡張の2つのBPF実装があります。

    したがって、BPF_JIT機能は、有効になっている実装の少なくとも1つに依存します。

    config BPF_JIT
        depends on HAVE_CBPF_JIT || HAVE_EBPF_JIT
    

    BFP_JITには2つの可能な実装があるため、Kconfigは適切なものを適切に自動的に選択できませんでした。

    「依存関係が1つも満たされていない場合は、デフォルトでこれを選択する」と言いたい場合がありますが、これにより、さらに自動化できます。

「何かがmenuconfigの別のオプションを隠す」効果もありますが、これらは単に綿毛です:-)