| Age | Commit message (Collapse) | Author |
|---|
|
Think I had it in the back of my head somewhere that not invalidating
undefined symbols could break some obscure cases, but turns out it's
perfectly safe: Nothing can change the value of an undefined symbol.
They always get their name as their value.
There's no need to unset user values on them either, because
set_user_value() already refuses to to set one on them.
Lets us get rid of the Python 2/3 compatibility hack and instead iterate
over a plain list of defined symbols.
|
|
Was added upstream in 31847b67 (kconfig: allow use of relations other
than (in)equality). Completely unused (and undocumented) in the kernel
except for in DEBUG_UART_8250_WORD in arch/arm/Kconfig.debug:
depends on DEBUG_UART_8250_SHIFT >= 2
(That line was added before lt/gt support by the way, and assumed a
feature that wasn't there.)
This change (and the upstream one) also slightly changes how
(in)equality comparisons work, making e.g.
MY_HEX = 0x00037
evaluate to 'y' if MY_HEX is 0x37. Prior to this change, the strings
needed to match exactly.
|
|
This is like a 'select' that only changes the default value of a symbol,
not limiting what values the user can set it to (with one exception: A
symbol implied to 'y' can't be set to 'm').
Symbol.get_implied_symbols() was added, corresponding to
Symbol.get_selected_symbols(), and Symbol.__str__() was extended to
print implied symbols and weak reverse dependencies. Weak reverse
dependencies are the 'imply' version of 'select's reverse dependencies.
|
|
|
