| Server IP : 127.0.0.2 / Your IP : 18.119.132.21 Web Server : Apache/2.4.18 (Ubuntu) System : User : www-data ( ) PHP Version : 7.0.33-0ubuntu0.16.04.16 Disable Function : disk_free_space,disk_total_space,diskfreespace,dl,exec,fpaththru,getmyuid,getmypid,highlight_file,ignore_user_abord,leak,listen,link,opcache_get_configuration,opcache_get_status,passthru,pcntl_alarm,pcntl_fork,pcntl_waitpid,pcntl_wait,pcntl_wifexited,pcntl_wifstopped,pcntl_wifsignaled,pcntl_wexitstatus,pcntl_wtermsig,pcntl_wstopsig,pcntl_signal,pcntl_signal_dispatch,pcntl_get_last_error,pcntl_strerror,pcntl_sigprocmask,pcntl_sigwaitinfo,pcntl_sigtimedwait,pcntl_exec,pcntl_getpriority,pcntl_setpriority,php_uname,phpinfo,posix_ctermid,posix_getcwd,posix_getegid,posix_geteuid,posix_getgid,posix_getgrgid,posix_getgrnam,posix_getgroups,posix_getlogin,posix_getpgid,posix_getpgrp,posix_getpid,posix,_getppid,posix_getpwnam,posix_getpwuid,posix_getrlimit,posix_getsid,posix_getuid,posix_isatty,posix_kill,posix_mkfifo,posix_setegid,posix_seteuid,posix_setgid,posix_setpgid,posix_setsid,posix_setuid,posix_times,posix_ttyname,posix_uname,pclose,popen,proc_open,proc_close,proc_get_status,proc_nice,proc_terminate,shell_exec,source,show_source,system,virtual MySQL : OFF | cURL : ON | WGET : ON | Perl : ON | Python : ON | Sudo : ON | Pkexec : ON Directory : /lib/modules/4.4.0-1084-aws/build/Documentation/kbuild/ |
Upload File : |
# Cumulative Kconfig recursive issue # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # # Test with: # # make KBUILD_KCONFIG=Documentation/kbuild/Kconfig.recursion-issue-02 allnoconfig # # The recursive limitations with Kconfig has some non intuitive implications on # kconfig sematics which are documented here. One known practical implication # of the recursive limitation is that drivers cannot negate features from other # drivers if they share a common core requirement and use disjoint semantics to # annotate those requirements, ie, some drivers use "depends on" while others # use "select". For instance it means if a driver A and driver B share the same # core requirement, and one uses "select" while the other uses "depends on" to # annotate this, all features that driver A selects cannot now be negated by # driver B. # # A perhaps not so obvious implication of this is that, if semantics on these # core requirements are not carefully synced, as drivers evolve features # they select or depend on end up becoming shared requirements which cannot be # negated by other drivers. # # The example provided in Documentation/kbuild/Kconfig.recursion-issue-02 # describes a simple driver core layout of example features a kernel might # have. Let's assume we have some CORE functionality, then the kernel has a # series of bells and whistles it desires to implement, its not so advanced so # it only supports bells at this time: CORE_BELL_A and CORE_BELL_B. If # CORE_BELL_A has some advanced feature CORE_BELL_A_ADVANCED which selects # CORE_BELL_A then CORE_BELL_A ends up becoming a common BELL feature which # other bells in the system cannot negate. The reason for this issue is # due to the disjoint use of semantics on expressing each bell's relationship # with CORE, one uses "depends on" while the other uses "select". Another # more important reason is that kconfig does not check for dependencies listed # under 'select' for a symbol, when such symbols are selected kconfig them # as mandatory required symbols. For more details on the heavy handed nature # of select refer to Documentation/kbuild/Kconfig.select-break # # To fix this the "depends on CORE" must be changed to "select CORE", or the # "select CORE" must be changed to "depends on CORE". # # For an example real world scenario issue refer to the attempt to remove # "select FW_LOADER" [0], in the end the simple alternative solution to this # problem consisted on matching semantics with newly introduced features. # # [0] http://lkml.kernel.org/r/1432241149-8762-1-git-send-email-mcgrof@do-not-panic.com mainmenu "Simple example to demo cumulative kconfig recursive dependency implication" config CORE tristate config CORE_BELL_A tristate depends on CORE config CORE_BELL_A_ADVANCED tristate select CORE_BELL_A config CORE_BELL_B tristate depends on !CORE_BELL_A select CORE