linux-kernel - Re: [PATCH] android: use "menuconfig" menu entry type for CONFIG

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <o0173nqs-17o2-s745-s2p-8q1q371r36r0@vanv.qr>
Date:   Thu, 30 Dec 2021 18:36:20 +0100 (CET)
From:   Jan Engelhardt <jengelh@...i.de>
To:     Greg KH <gregkh@...uxfoundation.org>
cc:     linux-kernel@...r.kernel.org, tkjos@...roid.com
Subject: Re: [PATCH] android: use "menuconfig" menu entry type for
 CONFIG_ANDROID

On Thursday 2021-12-30 17:58, Greg KH wrote:
>On Thu, Dec 30, 2021 at 03:50:02PM +0100, Jan Engelhardt wrote:
>> Allow disabling the Android driver section from within the Device
>> Drivers submenu, without having to descend into the Android drivers
>> submenu first.

>> -config ANDROID
>> +menuconfig ANDROID
>
>But, when you do this, you loose these lines from the .config file,
>resulting in this diff in the file:
>
>-#
>-# Android
>-#
> CONFIG_ANDROID=y
> CONFIG_ANDROID_BINDER_IPC=y
> CONFIG_ANDROID_BINDERFS=y
> CONFIG_ANDROID_BINDER_DEVICES="binder"
> CONFIG_ANDROID_BINDER_IPC_SELFTEST=y
>-# end of Android
>-
>
>Is that really a good idea?

Humour me - what information did "# Android" convey
that CONFIG_ANDROID= didn't already?

>What's the default these days?

There isn't really a default. When someone edits a Kconfig file to
add options for a new knob, they have to decide for one or the other.
At worst, they'll just copy from some other Kconfig file or the
documentation without making a conscious decision.

As you can see in the Device Drivers menu when running the `make 
menuconfig` command, it's a mix, but with a clear tendency to go with 
the menuconfig type. We used to have much less menuconfig-type options 
in the olden days of 2.4.x or so. I would therefore make the case that, 
on the whole, menuconfig-typed options are/should be used whenever 
possible.

  -*- PPS support  --->
      PTP clock support  --->
  [ ] Pin controllers  ----
  [ ] GPIO Support  ----
  < > Dallas's 1-wire support  ----
  [ ] Board level reset or power off  ----
  -*- Power supply class support  --->
  -*- Hardware Monitoring support  --->
  -*- Thermal drivers  --->
  [*] Watchdog Timer Support  --->
  < > Sonics Silicon Backplane support  ----
  < > Broadcom specific AMBA  ----
      Multifunction device drivers  --->
  [ ] Voltage and Current Regulator Support  ----
  < > Remote Controller support  ----
      CEC support  --->
  < > Multimedia support  ----
      Graphics support  --->
  <*> Sound card support  --->

There's just no GPIO, W1 or SSB in most contemporary desktop and
laptop x86s for example, and servers generally come without sound, so
it's nice to just hit {N DOWN}*.. quickly rather than having to
{ENTER N RIGHT ENTER DOWN}* to disable driver categories.

>Also, to be pedantic, this is a [v2] patch, right?  :)

Sorry, I have been working too long with sites like github et al
where diff -p0/p1 does not play a role (since one is sending commits
not diffs), nor version markers are needed (an update will simply be
appended to the end of a ticket/PR).