On x86-64 menuconfig, CONFIG_VT is forced on (in drivers->char devices->virtual
terminal), but the help doesn't mention a "selects", and I didn't spot anything
obvious in "find . -name 'Kconfig*' | xargs grep -rw VT".
Congratulations, you've reinvented "come from". I'm mostly familiar with the
kconfig plumbing from _before_ you made it turing complete: how do I navigate this?
I'm guessing "stick printfs into the menuconfig binary" is the recommended next
step for investigating this? Or is there a trick I'm missing?
Rob
On 12/30/19 4:30 PM, Rob Landley wrote:
> On x86-64 menuconfig, CONFIG_VT is forced on (in drivers->char devices->virtual
> terminal), but the help doesn't mention a "selects", and I didn't spot anything
> obvious in "find . -name 'Kconfig*' | xargs grep -rw VT".
>
> Congratulations, you've reinvented "come from". I'm mostly familiar with the
> kconfig plumbing from _before_ you made it turing complete: how do I navigate this?
>
> I'm guessing "stick printfs into the menuconfig binary" is the recommended next
> step for investigating this? Or is there a trick I'm missing?
I've never had to resort to that trick.
> Rob
>
config VT
bool "Virtual terminal" if EXPERT
depends on !UML
select INPUT
default y
^^^^^^^^^^^^^^^^^^^
That's all it takes ^^^^^^^^^^^^^^^^.
Does that explain it? Maybe I don't understand the problem.
--
~Randy
On 12/30/19 6:36 PM, Randy Dunlap wrote:
> On 12/30/19 4:30 PM, Rob Landley wrote:
>> On x86-64 menuconfig, CONFIG_VT is forced on (in drivers->char devices->virtual
>> terminal), but the help doesn't mention a "selects", and I didn't spot anything
>> obvious in "find . -name 'Kconfig*' | xargs grep -rw VT".
>>
>> Congratulations, you've reinvented "come from". I'm mostly familiar with the
>> kconfig plumbing from _before_ you made it turing complete: how do I navigate this?
>>
>> I'm guessing "stick printfs into the menuconfig binary" is the recommended next
>> step for investigating this? Or is there a trick I'm missing?
>
> I've never had to resort to that trick.
>
>> Rob
>>
>
> config VT
> bool "Virtual terminal" if EXPERT
> depends on !UML
> select INPUT
> default y
> ^^^^^^^^^^^^^^^^^^^
>
> That's all it takes ^^^^^^^^^^^^^^^^.
Try to switch it off. It won't let you, it's forced on by something else. The
help doesn't say what. (That select means it's forcing CONFIG_INPUT on?)
> Does that explain it? Maybe I don't understand the problem.
It's possible I don't either. I can disable it when when I start from
allnoconfig and then switch CONFIG_TTY on (at which point it defaults to y, but
can be disabled).
Rob
On 12/30/19 4:53 PM, Rob Landley wrote:
>
>
> On 12/30/19 6:36 PM, Randy Dunlap wrote:
>> On 12/30/19 4:30 PM, Rob Landley wrote:
>>> On x86-64 menuconfig, CONFIG_VT is forced on (in drivers->char devices->virtual
>>> terminal), but the help doesn't mention a "selects", and I didn't spot anything
>>> obvious in "find . -name 'Kconfig*' | xargs grep -rw VT".
>>>
>>> Congratulations, you've reinvented "come from". I'm mostly familiar with the
>>> kconfig plumbing from _before_ you made it turing complete: how do I navigate this?
>>>
>>> I'm guessing "stick printfs into the menuconfig binary" is the recommended next
>>> step for investigating this? Or is there a trick I'm missing?
>>
>> I've never had to resort to that trick.
>>
>>> Rob
>>>
>>
>> config VT
>> bool "Virtual terminal" if EXPERT
>> depends on !UML
>> select INPUT
>> default y
>> ^^^^^^^^^^^^^^^^^^^
>>
>> That's all it takes ^^^^^^^^^^^^^^^^.
>
> Try to switch it off. It won't let you, it's forced on by something else. The
> help doesn't say what. (That select means it's forcing CONFIG_INPUT on?)
>
>> Does that explain it? Maybe I don't understand the problem.
>
> It's possible I don't either. I can disable it when when I start from
> allnoconfig and then switch CONFIG_TTY on (at which point it defaults to y, but
> can be disabled).
#
# Character devices
#
CONFIG_TTY=y
# CONFIG_VT is not set
But first you must set/enable EXPERT. See the bool prompt.
--
~Randy
On 12/30/19 6:59 PM, Randy Dunlap wrote:
> #
> # Character devices
> #
> CONFIG_TTY=y
> # CONFIG_VT is not set
>
> But first you must set/enable EXPERT. See the bool prompt.
Wait, the if doesn't _disable_ the symbol? It disables _editability_ of the
symbol, but the symbol can still be on (and displayed) when the if is false?
(Why would...)
Ok. Thanks for pointing that out. Any idea why the menuconfig help text has no
mention of this?
Rob
On Mon, Dec 30, 2019 at 06:30:15PM -0600, Rob Landley wrote:
> On x86-64 menuconfig, CONFIG_VT is forced on (in drivers->char devices->virtual
> terminal), but the help doesn't mention a "selects", and I didn't spot anything
> obvious in "find . -name 'Kconfig*' | xargs grep -rw VT".
It's forced on because of this:
config VT
bool "Virtual terminal" if EXPERT
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The above is syntatic sugar for this:
bool
prompt "Virtual terminal" if EXPERT
What this means is that the prompt is shown only if CONFIG_EXPERT is
enabled. If CONFIG_EXPERT is not set, then the default value (which
for CONFIG_VT is "yes") is used, with no way to change it.
Basically, this is because we don't want naive users to build a kernel
which displays nothing on the console; for PC class systems, 99.99% of
the time, you really do want the virtual terminal enabled.
> Congratulations, you've reinvented "come from". I'm mostly familiar with the
> kconfig plumbing from _before_ you made it turing complete: how do I navigate this?
In the case where something was actually selected, it is explained as
such when you search for that config variable. So for example, if you
run "make menuconfig", and then type '/' to search for a configuration
parameter, and then type "CONFIG_JBD2" and return. What you will see
is this:
Symbol: JBD2 [=y] │
Type : tristate │
Defined at fs/jbd2/Kconfig:2 │
Depends on: BLOCK [=y] │
Selects: CRC32 [=y] && CRYPTO [=y] && CRYPTO_CRC32C [=y] │
Selected by [y]: │
- EXT4_FS [=y] && BLOCK [=y] │
Selected by [n]: │
- EXT3_FS [=n] && BLOCK [=y] │
- OCFS2_FS [=n] && BLOCK [=y] && NET [=y] && SYSFS [=y] && CONFIGFS_FS [=y]
The values in square brackets tell you what the current value of these
configuration parameters. So it tells you that CONFIG_JBD2 is yes,
CONFIG_BLOCK is yes, EXT3_FS is no, OCFS2_FS is no, etc.
It also tells you that it is currently selected automatically because
CONFIG_EXT4_FS and CONFIG_BLOCK is enabled. If CONFIG_EXT3_FS and
CONFIG_BLOCK was yes, that would also cause CONFIG_JBD2 to be
selected.
And since CONFIG_JBD2 is enabled, it will force CONFIG_CRC32,
CONFIG_CRYPTO, and CONFIG_CRC32C to be selected.
It also tells you that you can find the actual definition at
fs/jbd2/Kconfig, at line #2.
> I'm guessing "stick printfs into the menuconfig binary" is the recommended next
> step for investigating this? Or is there a trick I'm missing?
See above. The menuconfig configuration parameter search feature
tells you all about how a particular CONFIG_XXX, and what dependencies
to be enabled in order for you to be able enable that parameter, and
why it might have been enabled via the select command.
What's not there is an explanation for why a parameter like CONFIG_VT
is enabled. Right now, /CONFIG_VT will display:
Symbol: VT [=y]
Type : bool
Prompt: Virtual terminal
Location:
-> Device Drivers
-> Character devices
(1) -> Enable TTY (TTY [=y])
Defined at drivers/tty/Kconfig:13
Depends on: TTY [=y] && !UML
Selects: INPUT [=y]
Now, if you look at line 13 of drivers/tty/Kconfig, you'd see:
config VT
bool "Virtual terminal" if EXPERT
depends on !UML
select INPUT
default y
---help---
If you say Y here, you will get support for terminal devices with
...
Perhaps it would be nice if the output of /CONFIG_VT included
something like:
Prompt requires CONFIG_EXPERT [=n], default y
I'm sure the kbuild maintainers would love to consider a patch which
did this. :-)
Cheers,
- Ted
On 12/30/19 5:45 PM, Rob Landley wrote:
> On 12/30/19 6:59 PM, Randy Dunlap wrote:
>> #
>> # Character devices
>> #
>> CONFIG_TTY=y
>> # CONFIG_VT is not set
>>
>> But first you must set/enable EXPERT. See the bool prompt.
>
> Wait, the if doesn't _disable_ the symbol? It disables _editability_ of the
> symbol, but the symbol can still be on (and displayed) when the if is false?
Yes, displayed but not edited.
> (Why would...)
>
> Ok. Thanks for pointing that out. Any idea why the menuconfig help text has no
> mention of this?
Hm, it's disappointing that EXPERT is not mentioned there somewhere,
when using menuconfig or nconfig.
When using xconfig, and selecting "Virtual terminal" VT, xconfig help does say:
type: bool
unknown property: symbol
dep: TTY && !UML
prompt: Virtual terminal
dep: TTY && !UML && EXPERT <<<<< so the prompt depends on EXPERT
select: INPUT
dep: TTY && !UML
default: y
dep: TTY && !UML
--
~Randy
On 12/30/19 7:45 PM, Rob Landley wrote:
> On 12/30/19 6:59 PM, Randy Dunlap wrote:
>> #
>> # Character devices
>> #
>> CONFIG_TTY=y
>> # CONFIG_VT is not set
>>
>> But first you must set/enable EXPERT. See the bool prompt.
>
> Wait, the if doesn't _disable_ the symbol? It disables _editability_ of the
> symbol, but the symbol can still be on (and displayed) when the if is false?
> (Why would...)
>
> Ok. Thanks for pointing that out. Any idea why the menuconfig help text has no
> mention of this?
So if I disable CONFIG_EXPERT, using miniconfig I then need to manually switch on:
./init/Kconfig: bool "Namespaces support" if EXPERT
./init/Kconfig: bool "Multiple users, groups and capabilities support" if EXPERT
./init/Kconfig: bool "Sysfs syscall support" if EXPERT
./init/Kconfig: bool "open by fhandle syscalls" if EXPERT
./init/Kconfig: bool "Posix Clocks & timers" if EXPERT
./init/Kconfig: bool "Enable support for printk" if EXPERT
./init/Kconfig: bool "BUG() support" if EXPERT
./init/Kconfig: bool "Enable ELF core dumps" if EXPERT
./init/Kconfig: bool "Enable full-sized data structures for core" if EXPERT
./init/Kconfig: bool "Enable futex support" if EXPERT
./init/Kconfig: bool "Enable eventpoll support" if EXPERT
./init/Kconfig: bool "Enable signalfd() system call" if EXPERT
./init/Kconfig: bool "Enable timerfd() system call" if EXPERT
./init/Kconfig: bool "Enable eventfd() system call" if EXPERT
./init/Kconfig: bool "Use full shmem filesystem" if EXPERT
./init/Kconfig: bool "Enable AIO support" if EXPERT
./init/Kconfig: bool "Enable IO uring support" if EXPERT
./init/Kconfig: bool "Enable madvise/fadvise syscalls" if EXPERT
./init/Kconfig: bool "Enable membarrier() system call" if EXPERT
./init/Kconfig: bool "Load all symbols for debugging/ksymoops" if EXPERT
./init/Kconfig: bool "Enable rseq() system call" if EXPERT
./init/Kconfig: bool "Enabled debugging of rseq() system call" if EXPERT
./init/Kconfig: bool "PC/104 support" if EXPERT
./init/Kconfig: bool "Enable VM event counters for /proc/vmstat" if EXPERT
plus of course
./arch/x86/Kconfig.cpu: bool "Supported processor vendors" if EXPERT
./arch/x86/Kconfig: bool "DMA memory allocation support" if EXPERT
./arch/x86/Kconfig: bool "Enable DMI scanning" if EXPERT
./arch/x86/Kconfig: bool "Enable support for 16-bit segments" if EXPERT
./arch/x86/Kconfig: bool "Enable vsyscall emulation" if EXPERT
./arch/x86/Kconfig: bool "Enable the LDT (local descriptor table)" if EXPERT
./arch/x86/Kconfig: bool "Read CNB20LE Host Bridge Windows" if EXPERT
./arch/x86/Kconfig: bool "ISA bus support on modern systems" if EXPERT
./arch/x86/Kconfig: bool "ISA-style DMA support" if (X86_64 && EXPERT)
So nobody noticed you have a structural "this config option actually switches
this thing _off_" implemented via magic symbol then?
I think the right fix here involves running sed after kconfig does its thing...
Rob
On 12/30/19 6:04 PM, Rob Landley wrote:
>
>
> On 12/30/19 7:45 PM, Rob Landley wrote:
>> On 12/30/19 6:59 PM, Randy Dunlap wrote:
>>> #
>>> # Character devices
>>> #
>>> CONFIG_TTY=y
>>> # CONFIG_VT is not set
>>>
>>> But first you must set/enable EXPERT. See the bool prompt.
>>
>> Wait, the if doesn't _disable_ the symbol? It disables _editability_ of the
>> symbol, but the symbol can still be on (and displayed) when the if is false?
>> (Why would...)
>>
>> Ok. Thanks for pointing that out. Any idea why the menuconfig help text has no
>> mention of this?
>
> So if I disable CONFIG_EXPERT, using miniconfig I then need to manually switch on:
>
> ./init/Kconfig: bool "Namespaces support" if EXPERT
> ./init/Kconfig: bool "Multiple users, groups and capabilities support" if EXPERT
> ./init/Kconfig: bool "Sysfs syscall support" if EXPERT
> ./init/Kconfig: bool "open by fhandle syscalls" if EXPERT
> ./init/Kconfig: bool "Posix Clocks & timers" if EXPERT
> ./init/Kconfig: bool "Enable support for printk" if EXPERT
> ./init/Kconfig: bool "BUG() support" if EXPERT
> ./init/Kconfig: bool "Enable ELF core dumps" if EXPERT
> ./init/Kconfig: bool "Enable full-sized data structures for core" if EXPERT
> ./init/Kconfig: bool "Enable futex support" if EXPERT
> ./init/Kconfig: bool "Enable eventpoll support" if EXPERT
> ./init/Kconfig: bool "Enable signalfd() system call" if EXPERT
> ./init/Kconfig: bool "Enable timerfd() system call" if EXPERT
> ./init/Kconfig: bool "Enable eventfd() system call" if EXPERT
> ./init/Kconfig: bool "Use full shmem filesystem" if EXPERT
> ./init/Kconfig: bool "Enable AIO support" if EXPERT
> ./init/Kconfig: bool "Enable IO uring support" if EXPERT
> ./init/Kconfig: bool "Enable madvise/fadvise syscalls" if EXPERT
> ./init/Kconfig: bool "Enable membarrier() system call" if EXPERT
> ./init/Kconfig: bool "Load all symbols for debugging/ksymoops" if EXPERT
> ./init/Kconfig: bool "Enable rseq() system call" if EXPERT
> ./init/Kconfig: bool "Enabled debugging of rseq() system call" if EXPERT
> ./init/Kconfig: bool "PC/104 support" if EXPERT
> ./init/Kconfig: bool "Enable VM event counters for /proc/vmstat" if EXPERT
>
> plus of course
>
> ./arch/x86/Kconfig.cpu: bool "Supported processor vendors" if EXPERT
> ./arch/x86/Kconfig: bool "DMA memory allocation support" if EXPERT
> ./arch/x86/Kconfig: bool "Enable DMI scanning" if EXPERT
> ./arch/x86/Kconfig: bool "Enable support for 16-bit segments" if EXPERT
> ./arch/x86/Kconfig: bool "Enable vsyscall emulation" if EXPERT
> ./arch/x86/Kconfig: bool "Enable the LDT (local descriptor table)" if EXPERT
> ./arch/x86/Kconfig: bool "Read CNB20LE Host Bridge Windows" if EXPERT
> ./arch/x86/Kconfig: bool "ISA bus support on modern systems" if EXPERT
> ./arch/x86/Kconfig: bool "ISA-style DMA support" if (X86_64 && EXPERT)
>
> So nobody noticed you have a structural "this config option actually switches
> this thing _off_" implemented via magic symbol then?
I guess nobody had a problem with it for the last 10 or 15 or 20 years.
> I think the right fix here involves running sed after kconfig does its thing...
I doubt that would work, but if it does, go for it.
--
~Randy
On Mon, Dec 30, 2019 at 06:30:15PM -0600, Rob Landley wrote:
> On x86-64 menuconfig, CONFIG_VT is forced on (in drivers->char devices->virtual
> terminal), but the help doesn't mention a "selects", and I didn't spot anything
> obvious in "find . -name 'Kconfig*' | xargs grep -rw VT".
>
> Congratulations, you've reinvented "come from". I'm mostly familiar with the
> kconfig plumbing from _before_ you made it turing complete: how do I navigate this?
>
> I'm guessing "stick printfs into the menuconfig binary" is the recommended next
> step for investigating this? Or is there a trick I'm missing?
config VT
bool "Virtual terminal" if EXPERT
IOW, it's only conrollable if EXPERT is set. Finding CONFIG_EXPERT, setting it
and turning CONFIG_VT off is left as an exercise for reader; ceasing the
indignant whining for long enough to do that might or might not be doable -
up to you.
On Mon, Dec 30, 2019 at 06:03:26PM -0800, Randy Dunlap wrote:
> >
> > So if I disable CONFIG_EXPERT, using miniconfig I then need to manually switch on:
> >
> > ./init/Kconfig: bool "Namespaces support" if EXPERT
> >
> > So nobody noticed you have a structural "this config option actually switches
> > this thing _off_" implemented via magic symbol then?
Perhaps because the right thing happens if you enable CONFIG_EXPERT
using "make menuconfig"? It also looks like the right thing happens
if you edit the .config and then run "make oldconfig".
Personally, I never use miniconfig, so it's not anything *I* ever
noticed in all of my years of kernel development. Usually, the way
that I manage configs is "make menuconfig", or editing the .config
directly, or "make savedefconfig" / "make olddefconfig".
Cheers,
- Ted
On Mon, Dec 30, 2019 at 08:04:35PM -0600, Rob Landley wrote:
>
>
> On 12/30/19 7:45 PM, Rob Landley wrote:
> > On 12/30/19 6:59 PM, Randy Dunlap wrote:
> >> #
> >> # Character devices
> >> #
> >> CONFIG_TTY=y
> >> # CONFIG_VT is not set
> >>
> >> But first you must set/enable EXPERT. See the bool prompt.
> >
> > Wait, the if doesn't _disable_ the symbol? It disables _editability_ of the
> > symbol, but the symbol can still be on (and displayed) when the if is false?
> > (Why would...)
> >
> > Ok. Thanks for pointing that out. Any idea why the menuconfig help text has no
> > mention of this?
>
> So if I disable CONFIG_EXPERT, using miniconfig I then need to manually switch on:
>
> ./init/Kconfig: bool "Namespaces support" if EXPERT
> ./init/Kconfig: bool "Multiple users, groups and capabilities support" if EXPERT
> ./init/Kconfig: bool "Sysfs syscall support" if EXPERT
> ./init/Kconfig: bool "open by fhandle syscalls" if EXPERT
> ./init/Kconfig: bool "Posix Clocks & timers" if EXPERT
> ./init/Kconfig: bool "Enable support for printk" if EXPERT
> ./init/Kconfig: bool "BUG() support" if EXPERT
> ./init/Kconfig: bool "Enable ELF core dumps" if EXPERT
> ./init/Kconfig: bool "Enable full-sized data structures for core" if EXPERT
> ./init/Kconfig: bool "Enable futex support" if EXPERT
> ./init/Kconfig: bool "Enable eventpoll support" if EXPERT
> ./init/Kconfig: bool "Enable signalfd() system call" if EXPERT
> ./init/Kconfig: bool "Enable timerfd() system call" if EXPERT
> ./init/Kconfig: bool "Enable eventfd() system call" if EXPERT
> ./init/Kconfig: bool "Use full shmem filesystem" if EXPERT
> ./init/Kconfig: bool "Enable AIO support" if EXPERT
> ./init/Kconfig: bool "Enable IO uring support" if EXPERT
> ./init/Kconfig: bool "Enable madvise/fadvise syscalls" if EXPERT
> ./init/Kconfig: bool "Enable membarrier() system call" if EXPERT
> ./init/Kconfig: bool "Load all symbols for debugging/ksymoops" if EXPERT
> ./init/Kconfig: bool "Enable rseq() system call" if EXPERT
> ./init/Kconfig: bool "Enabled debugging of rseq() system call" if EXPERT
> ./init/Kconfig: bool "PC/104 support" if EXPERT
> ./init/Kconfig: bool "Enable VM event counters for /proc/vmstat" if EXPERT
No. What you need is
* actually attempt to flip CONFIG_EXPERT (go to "General setup" submenu and
set "Configure standard kernel features (expert users)" there)
* check the resulting .config (or look at the items in question via
menuconfig)
* get enlightened
Rob, if you are in a mood for a long wank, it's your business. But try to avoid
spraying the results over public lists.
On Tue, Dec 31, 2019 at 02:40:54AM +0000, Al Viro wrote:
> On Mon, Dec 30, 2019 at 08:04:35PM -0600, Rob Landley wrote:
> >
> >
> > On 12/30/19 7:45 PM, Rob Landley wrote:
> > > On 12/30/19 6:59 PM, Randy Dunlap wrote:
> > >> #
> > >> # Character devices
> > >> #
> > >> CONFIG_TTY=y
> > >> # CONFIG_VT is not set
> > >>
> > >> But first you must set/enable EXPERT. See the bool prompt.
> > >
> > > Wait, the if doesn't _disable_ the symbol? It disables _editability_ of the
> > > symbol, but the symbol can still be on (and displayed) when the if is false?
> > > (Why would...)
> > >
> > > Ok. Thanks for pointing that out. Any idea why the menuconfig help text has no
> > > mention of this?
> >
> > So if I disable CONFIG_EXPERT, using miniconfig I then need to manually switch on:
> >
> > ./init/Kconfig: bool "Namespaces support" if EXPERT
> > ./init/Kconfig: bool "Multiple users, groups and capabilities support" if EXPERT
> > ./init/Kconfig: bool "Sysfs syscall support" if EXPERT
> > ./init/Kconfig: bool "open by fhandle syscalls" if EXPERT
> > ./init/Kconfig: bool "Posix Clocks & timers" if EXPERT
> > ./init/Kconfig: bool "Enable support for printk" if EXPERT
> > ./init/Kconfig: bool "BUG() support" if EXPERT
> > ./init/Kconfig: bool "Enable ELF core dumps" if EXPERT
> > ./init/Kconfig: bool "Enable full-sized data structures for core" if EXPERT
> > ./init/Kconfig: bool "Enable futex support" if EXPERT
> > ./init/Kconfig: bool "Enable eventpoll support" if EXPERT
> > ./init/Kconfig: bool "Enable signalfd() system call" if EXPERT
> > ./init/Kconfig: bool "Enable timerfd() system call" if EXPERT
> > ./init/Kconfig: bool "Enable eventfd() system call" if EXPERT
> > ./init/Kconfig: bool "Use full shmem filesystem" if EXPERT
> > ./init/Kconfig: bool "Enable AIO support" if EXPERT
> > ./init/Kconfig: bool "Enable IO uring support" if EXPERT
> > ./init/Kconfig: bool "Enable madvise/fadvise syscalls" if EXPERT
> > ./init/Kconfig: bool "Enable membarrier() system call" if EXPERT
> > ./init/Kconfig: bool "Load all symbols for debugging/ksymoops" if EXPERT
> > ./init/Kconfig: bool "Enable rseq() system call" if EXPERT
> > ./init/Kconfig: bool "Enabled debugging of rseq() system call" if EXPERT
> > ./init/Kconfig: bool "PC/104 support" if EXPERT
> > ./init/Kconfig: bool "Enable VM event counters for /proc/vmstat" if EXPERT
>
> No. What you need is
> * actually attempt to flip CONFIG_EXPERT (go to "General setup" submenu and
> set "Configure standard kernel features (expert users)" there)
> * check the resulting .config (or look at the items in question via
> menuconfig)
> * get enlightened
>
> Rob, if you are in a mood for a long wank, it's your business. But try to avoid
> spraying the results over public lists.
To elaborate: you are complaining about VT being treated the same way as e.g.
ELF_CORE or UID16. Which might or might not be reasonable, but kconfig folks
have nothing to do with that.
Your complaint is basically that the same thing is forcing all of those on
in default configs. Instead of having a separate ROB_WANTS_THOSE that would
prop the rest, but not VT (and frankly, quite a bit of that rest is
questionable for minimal setups). With ROB_WANTS_THOSE (or equivalent
information) enshrined in the kernel tree for your convenience.
Pardon me, but... why is that anyone else's problem?
On 12/30/19 8:52 PM, Al Viro wrote:
>> Rob, if you are in a mood for a long wank, it's your business. But try to avoid
>> spraying the results over public lists.
I don't post regularly here anymore, but it's good to see the code of conduct
and Linus's sabbatical have had a positive effect on the place in my absence.
> To elaborate: you are complaining about VT being treated the same way as e.g.
> ELF_CORE or UID16. Which might or might not be reasonable, but kconfig folks
> have nothing to do with that.
>
> Your complaint is basically that the same thing is forcing all of those on
> in default configs.
No, my complaint was that kconfig basically has the concept of symbols that turn
_off_ something that is otherwise on by default ("Disable X" instead of "Enable
X"), but it was implemented it in an awkward way then allowed to scale to silly
levels, and now the fact it exists is being used as evidence that it was a good
idea.
I had to work out a way to work around this design breakage, which I did and had
moved on before this email, but I thought pointing out the awkwardness might
help a design discussion. My mistake.
The thread _started_ because menuconfig help has a blind spot (which seemed like
a bug to me, it _used_ to say why), and then I found the syntax you changed a
year or two back non-obvious when I tried to RTFM but that part got answered.
> Instead of having a separate ROB_WANTS_THOSE that would
> prop the rest, but not VT (and frankly, quite a bit of that rest is
> questionable for minimal setups). With ROB_WANTS_THOSE (or equivalent
> information) enshrined in the kernel tree for your convenience.
>
> Pardon me, but... why is that anyone else's problem?
You drove everybody away who would express similar concerns years ago. None of
my co-workers have wanted to get linux-kernel on them in ages. (I thought that
sort of thing was why you were having a code of conduct and such, but apparently
not.)
*shrug* I'll try to be more proactive about stripping linux-kernel from the cc:
list once I've got a human's attention in a thread. (Or just try to dig up
somebody to email directly via git history and the maintainers file.)
I leave you to your sexual metaphors,
Rob
On Mon, Dec 30, 2019 at 09:27:50PM -0600, Rob Landley wrote:
> > Your complaint is basically that the same thing is forcing all of those on
> > in default configs.
>
> No, my complaint was that kconfig basically has the concept of symbols that turn
> _off_ something that is otherwise on by default ("Disable X" instead of "Enable
> X"), but it was implemented it in an awkward way then allowed to scale to silly
> levels, and now the fact it exists is being used as evidence that it was a good
> idea.
Where and by whom?
> I had to work out a way to work around this design breakage, which I did and had
> moved on before this email, but I thought pointing out the awkwardness might
> help a design discussion.
What design discussion? Where?
> My mistake.
Generally a passive-aggressive flame (complete with comparisons to INTERCAL)
and not a shred of reference to any design issues in it tends to
be rather ineffecient way to start such discussion...
> The thread _started_ because menuconfig help has a blind spot (which seemed like
> a bug to me, it _used_ to say why), and then I found the syntax you changed a
> year or two back non-obvious when I tried to RTFM but that part got answered.
_I_ have changed??? What the hell? I have never touched kconfig syntax in any
way; what are you talking about? Care to post commit IDs in question?
On Tue, Dec 31, 2019 at 03:53:19AM +0000, Al Viro wrote:
> On Mon, Dec 30, 2019 at 09:27:50PM -0600, Rob Landley wrote:
>
> > > Your complaint is basically that the same thing is forcing all of those on
> > > in default configs.
> >
> > No, my complaint was that kconfig basically has the concept of symbols that turn
> > _off_ something that is otherwise on by default ("Disable X" instead of "Enable
> > X"), but it was implemented it in an awkward way then allowed to scale to silly
> > levels, and now the fact it exists is being used as evidence that it was a good
> > idea.
>
> Where and by whom?
>
> > I had to work out a way to work around this design breakage, which I did and had
> > moved on before this email, but I thought pointing out the awkwardness might
> > help a design discussion.
>
> What design discussion? Where?
>
> > My mistake.
>
> Generally a passive-aggressive flame (complete with comparisons to INTERCAL)
> and not a shred of reference to any design issues in it tends to
> be rather ineffecient way to start such discussion...
>
> > The thread _started_ because menuconfig help has a blind spot (which seemed like
> > a bug to me, it _used_ to say why), and then I found the syntax you changed a
> > year or two back non-obvious when I tried to RTFM but that part got answered.
>
> _I_ have changed??? What the hell? I have never touched kconfig syntax in any
> way; what are you talking about? Care to post commit IDs in question?
BTW, in 2.6.12 drivers/char/Kconfig has
config VT
bool "Virtual terminal" if EMBEDDED
so the syntax appears to be identical all way back to 2005. Going to the historical
tree, we have
commit eda30c2b338cdc099951f45eb45d1ce7055706e3
Author: Alan Cox <[email protected]>
Date: Thu Jul 31 05:15:05 2003 -0700
[PATCH] console on by default if not embedded (save mucho pain)
(Andi Kleen)
diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index f0ce5d7473ad..d16c54b65102 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -5,8 +5,9 @@
menu "Character devices"
config VT
- bool "Virtual terminal"
+ bool "Virtual terminal" if EMBEDDED
requires INPUT=y
+ default y
So application of that particular syntax to VT goes back to 2003. I've no idea
how far back the syntax itself goes.
One change that might be relevant appears to have happened circa 3.15, when
allnoconfig started playing odd games with EXPERT; bisect points to
commit 5d2acfc7b974bbd3858b4dd3f2cdc6362dd8843a
Author: Josh Triplett <[email protected]>
Date: Mon Apr 7 15:39:09 2014 -0700
kconfig: make allnoconfig disable options behind EMBEDDED and EXPERT
Mind explaining what exactly are you talking about and how exactly have
I been involved in it? My only involvement with kconfig (thorough all
its history) had been
commit 6b87b70c5339f30e3c5b32085e69625906513dc2
Author: Al Viro <[email protected]>
Date: Thu Jan 14 18:13:49 2016 +0000
unbreak allmodconfig KCONFIG_ALLCONFIG=...
and
commit ce97e13e52848c6388598696b7d44748598db759
Author: Al Viro <[email protected]>
Date: Sun Oct 26 05:12:34 2008 +0000
fix allmodconfig breakage
Neither of those has happened within the last couple of years and if either
has caused any breakage relevant to whatever you are doing, I would rather
hear details. Certainly no syntax changes had been intended by either
commit and rereading those I see no likely candidates.
On Tue, Dec 31, 2019 at 04:18:15AM +0000, Al Viro wrote:
> > > The thread _started_ because menuconfig help has a blind spot (which seemed like
> > > a bug to me, it _used_ to say why), and then I found the syntax you changed a
> > > year or two back non-obvious when I tried to RTFM but that part got answered.
FWIW, the change of help message (from reporting
Depends on: TTY [=y] && !S390 && !UML && EXPERT [=n]
to
Depends on: TTY [=y] && !S390 && !UML)
seems to have come about in
commit bcdedcc1afd6ac91e15cb90aedaf8432f62fed13
Author: Wengmeiling <[email protected]>
Date: Tue Apr 30 15:28:46 2013 -0700
menuconfig: print more info for symbol without prompts
Doesn't seem to be intentional, going by the commit message,
and I'm not familiar enough with menuconfig guts to tell
more than that without serious RTFS.
So if you are refering to the help message contents (its syntax
doesn't seem to have changed), that would appear to be the
point when it has happened (3.10, six and half years ago).
If you are refering to the syntax of Kconfig itself, AFAICS
that has remained since the introduction of Kconfig back in
2002 - at least the earliest version of the parser seems
to have it that way. Hadn't checked how soon the first
users have appeared, but no later than in 2003. No idea
about the earlier history - it went into the tree in that
form.
No opinion about the merits of Kconfig syntax, BTW.
The older form of reported dependencies looks strange,
now that I look at it (never noticed that quirk back
then) - usually <something> && <option> [=n] would've
meant that the entire expression is false; if anything,
it might've been better to report the predicates on
prompt separately. No idea how hard would that be -
I hadn't looked into menuconfig guts for years, and
even then only casually.
FWIW, my only contact with KCONFIG_ALLCONFIG mechanism
had been on the build coverage side of things - i.e.
allmodconfig with fixed subset. Never played with
allnoconfig applications, but AFAICS the only (relatively)
recent change I'd done there hadn't changed allnoconfig
behaviour at all.
Commit bcdedcc1afd6 ("menuconfig: print more info for symbol without
prompts") moved some code from get_prompt_str to get_symbol_str so that
dependency information for symbols without prompts could be shown.
This code would be better copied rather than moved, as the change had
the side-effect of not showing any extra dependencies that the prompt
might have over the symbol.
Put back a copy of the dependency printing code in get_prompt_str.
The following is an example for NAMESPACES:
Before:
Symbol: NAMESPACES [=y]
Type : bool
Prompt: Namespaces support
Location:
(2) -> General setup
Defined at init/Kconfig:1064
Depends on: MULTIUSER [=y]
After:
Symbol: NAMESPACES [=y]
Type : bool
Prompt: Namespaces support
Visible if: MULTIUSER [=y] && EXPERT [=y]
Location:
(2) -> General setup
Defined at init/Kconfig:1064
Depends on: MULTIUSER [=y]
Fixes: bcdedcc1afd6 ("menuconfig: print more info for symbol without prompts")
Signed-off-by: Arvind Sankar <[email protected]>
---
scripts/kconfig/menu.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/scripts/kconfig/menu.c b/scripts/kconfig/menu.c
index d9d16469859a..c323ab4ac7c7 100644
--- a/scripts/kconfig/menu.c
+++ b/scripts/kconfig/menu.c
@@ -706,6 +706,12 @@ static void get_prompt_str(struct gstr *r, struct property *prop,
struct jump_key *jump = NULL;
str_printf(r, "Prompt: %s\n", prop->text);
+ if (!expr_is_yes(prop->visible.expr)) {
+ str_append(r, " Visible if: ");
+ expr_gstr_print(prop->visible.expr, r);
+ str_append(r, "\n");
+ }
+
menu = prop->menu->parent;
for (i = 0; menu != &rootmenu && i < 8; menu = menu->parent) {
bool accessible = menu_is_visible(menu);
--
2.24.1
On Wed, Jan 01, 2020 at 03:41:52PM -0500, Arvind Sankar wrote:
> Commit bcdedcc1afd6 ("menuconfig: print more info for symbol without
> prompts") moved some code from get_prompt_str to get_symbol_str so that
> dependency information for symbols without prompts could be shown.
>
> This code would be better copied rather than moved, as the change had
> the side-effect of not showing any extra dependencies that the prompt
> might have over the symbol.
>
> Put back a copy of the dependency printing code in get_prompt_str.
Umm... Is "visible" really accurate in this case? AFAICS, the
entry (and help for it) _is_ visible with EXPERT=n. OTOH, with
EXPERT=y and MULTIUSER=n it disappears completely.
I'm not familiar with kconfig guts (and not too concerned about that
feature of help there, TBH), but it looks like what you are printing
there is some mix of dependencies ("visible when") and selectability...
On Wed, Jan 01, 2020 at 09:04:26PM +0000, Al Viro wrote:
> On Wed, Jan 01, 2020 at 03:41:52PM -0500, Arvind Sankar wrote:
> > Commit bcdedcc1afd6 ("menuconfig: print more info for symbol without
> > prompts") moved some code from get_prompt_str to get_symbol_str so that
> > dependency information for symbols without prompts could be shown.
> >
> > This code would be better copied rather than moved, as the change had
> > the side-effect of not showing any extra dependencies that the prompt
> > might have over the symbol.
> >
> > Put back a copy of the dependency printing code in get_prompt_str.
>
> Umm... Is "visible" really accurate in this case? AFAICS, the
> entry (and help for it) _is_ visible with EXPERT=n. OTOH, with
> EXPERT=y and MULTIUSER=n it disappears completely.
>
> I'm not familiar with kconfig guts (and not too concerned about that
> feature of help there, TBH), but it looks like what you are printing
> there is some mix of dependencies ("visible when") and selectability...
Perhaps not the most accurate term. For NAMESPACES it has a submenu, so
it can't disappear as long as its selected, even if it's not editable
any more. A "leaf" level option like MULTIUSER, otoh, does disappear
completely (even though it's still selected).
But there are also things like CONFIG_VT, which stays visible, even
though its not a menu.. I think because there is a visible option that
depends on it and immediately follows, which menuconfig shows by
indenting. If the order of UNIX98_PTYS and VT_HW_CONSOLE_BINDING is
flipped in drivers/tty/Kconfig, then VT disappears when EXPERT=n.
Dunno, maybe Editable would be a better word than Visible?
On 1/1/20 2:26 PM, Arvind Sankar wrote:
> On Wed, Jan 01, 2020 at 09:04:26PM +0000, Al Viro wrote:
>> On Wed, Jan 01, 2020 at 03:41:52PM -0500, Arvind Sankar wrote:
>>> Commit bcdedcc1afd6 ("menuconfig: print more info for symbol without
>>> prompts") moved some code from get_prompt_str to get_symbol_str so that
>>> dependency information for symbols without prompts could be shown.
>>>
>>> This code would be better copied rather than moved, as the change had
>>> the side-effect of not showing any extra dependencies that the prompt
>>> might have over the symbol.
>>>
>>> Put back a copy of the dependency printing code in get_prompt_str.
>>
>> Umm... Is "visible" really accurate in this case? AFAICS, the
>> entry (and help for it) _is_ visible with EXPERT=n. OTOH, with
>> EXPERT=y and MULTIUSER=n it disappears completely.
>>
>> I'm not familiar with kconfig guts (and not too concerned about that
>> feature of help there, TBH), but it looks like what you are printing
>> there is some mix of dependencies ("visible when") and selectability...
>
> Perhaps not the most accurate term. For NAMESPACES it has a submenu, so
> it can't disappear as long as its selected, even if it's not editable
> any more. A "leaf" level option like MULTIUSER, otoh, does disappear
> completely (even though it's still selected).
>
> But there are also things like CONFIG_VT, which stays visible, even
> though its not a menu.. I think because there is a visible option that
> depends on it and immediately follows, which menuconfig shows by
> indenting. If the order of UNIX98_PTYS and VT_HW_CONSOLE_BINDING is
> flipped in drivers/tty/Kconfig, then VT disappears when EXPERT=n.
>
> Dunno, maybe Editable would be a better word than Visible?
I would prefer Editable instead of Visible.
and the Subject should be more than menuconfig since the patch also
"fixes" nconfig, xconfig, and gconfig.
Tested-by: Randy Dunlap <[email protected]>
Thanks.
--
~Randy
Commit bcdedcc1afd6 ("menuconfig: print more info for symbol without
prompts") moved some code from get_prompt_str to get_symbol_str so that
dependency information for symbols without prompts could be shown.
This code would be better copied rather than moved, as the change had
the side-effect of not showing any extra dependencies that the prompt
might have over the symbol.
Put back a copy of the dependency printing code in get_prompt_str.
The following is an example for NAMESPACES:
Before:
Symbol: NAMESPACES [=y]
Type : bool
Prompt: Namespaces support
Location:
(2) -> General setup
Defined at init/Kconfig:1064
Depends on: MULTIUSER [=y]
After:
Symbol: NAMESPACES [=y]
Type : bool
Prompt: Namespaces support
Editable if: MULTIUSER [=y] && EXPERT [=y]
Location:
(2) -> General setup
Defined at init/Kconfig:1064
Depends on: MULTIUSER [=y]
Fixes: bcdedcc1afd6 ("menuconfig: print more info for symbol without prompts")
Signed-off-by: Arvind Sankar <[email protected]>
---
scripts/kconfig/menu.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/scripts/kconfig/menu.c b/scripts/kconfig/menu.c
index d9d16469859a..6fbbe41302dc 100644
--- a/scripts/kconfig/menu.c
+++ b/scripts/kconfig/menu.c
@@ -706,6 +706,12 @@ static void get_prompt_str(struct gstr *r, struct property *prop,
struct jump_key *jump = NULL;
str_printf(r, "Prompt: %s\n", prop->text);
+ if (!expr_is_yes(prop->visible.expr)) {
+ str_append(r, " Editable if: ");
+ expr_gstr_print(prop->visible.expr, r);
+ str_append(r, "\n");
+ }
+
menu = prop->menu->parent;
for (i = 0; menu != &rootmenu && i < 8; menu = menu->parent) {
bool accessible = menu_is_visible(menu);
--
2.24.1
On Fri, Jan 3, 2020 at 8:14 AM Arvind Sankar <[email protected]> wrote:
>
> Commit bcdedcc1afd6 ("menuconfig: print more info for symbol without
> prompts") moved some code from get_prompt_str to get_symbol_str so that
> dependency information for symbols without prompts could be shown.
>
> This code would be better copied rather than moved, as the change had
> the side-effect of not showing any extra dependencies that the prompt
> might have over the symbol.
>
> Put back a copy of the dependency printing code in get_prompt_str.
>
> The following is an example for NAMESPACES:
>
> Before:
> Symbol: NAMESPACES [=y]
> Type : bool
> Prompt: Namespaces support
> Location:
> (2) -> General setup
> Defined at init/Kconfig:1064
> Depends on: MULTIUSER [=y]
>
> After:
> Symbol: NAMESPACES [=y]
> Type : bool
> Prompt: Namespaces support
> Editable if: MULTIUSER [=y] && EXPERT [=y]
> Location:
> (2) -> General setup
> Defined at init/Kconfig:1064
> Depends on: MULTIUSER [=y]
>
> Fixes: bcdedcc1afd6 ("menuconfig: print more info for symbol without prompts")
> Signed-off-by: Arvind Sankar <[email protected]>
> ---
I had already applied the following patch;
https://patchwork.kernel.org/patch/11298143/
It it available in linux-next.
> scripts/kconfig/menu.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/scripts/kconfig/menu.c b/scripts/kconfig/menu.c
> index d9d16469859a..6fbbe41302dc 100644
> --- a/scripts/kconfig/menu.c
> +++ b/scripts/kconfig/menu.c
> @@ -706,6 +706,12 @@ static void get_prompt_str(struct gstr *r, struct property *prop,
> struct jump_key *jump = NULL;
>
> str_printf(r, "Prompt: %s\n", prop->text);
> + if (!expr_is_yes(prop->visible.expr)) {
> + str_append(r, " Editable if: ");
> + expr_gstr_print(prop->visible.expr, r);
> + str_append(r, "\n");
> + }
> +
> menu = prop->menu->parent;
> for (i = 0; menu != &rootmenu && i < 8; menu = menu->parent) {
> bool accessible = menu_is_visible(menu);
> --
> 2.24.1
>
--
Best Regards
Masahiro Yamada
On Fri, Jan 03, 2020 at 11:10:28AM +0900, Masahiro Yamada wrote:
>
> I had already applied the following patch;
> https://patchwork.kernel.org/patch/11298143/
>
> It it available in linux-next.
>
Oh cool
On 31.12.19 02:55, Theodore Y. Ts'o wrote:
Hi,
> What this means is that the prompt is shown only if CONFIG_EXPERT is
> enabled. If CONFIG_EXPERT is not set, then the default value (which
> for CONFIG_VT is "yes") is used, with no way to change it.
So, if one manually changes that in .config and re-runs 'make
menuconfig' again, it will be forced back to the default ?
> What's not there is an explanation for why a parameter like CONFIG_VT
> is enabled.
That actually would be a good thing to have. I already had lots of cases
where I had to spend quite some time in order to find out what caused
something to be enabled/disabled/disappearing.
--mtx
--
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
[email protected] -- +49-151-27565287