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] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wj+4yA5jtzbTjctrk7Xu+88H=it2m5a-bpnnFeCQP7r=A@mail.gmail.com>
Date: Tue, 16 Jul 2024 11:08:33 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Bartosz Golaszewski <brgl@...ev.pl>
Cc: Bjorn Helgaas <bhelgaas@...gle.com>, linux-pci@...r.kernel.org, 
	linux-kernel@...r.kernel.org, 
	Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
Subject: Re: [PATCH] PCI/pwrctl: reduce the amount of Kconfig noise

On Tue, 16 Jul 2024 at 08:23, Bartosz Golaszewski <brgl@...ev.pl> wrote:
>
> Let's remove the public menuconfig entry for PCI pwrctl and instead
> default the relevant symbol to 'm' only for the architectures that
> actually need it.

This feels like you should just use "select" instead.

IOW, don't make PCI_PWRCTL_PWRSEQ a question at all. Instead, have the
drivers that need it just select it automatically.

It's much better to ask people "do you have hardware XYZ" that they
can hopefully answer, and then we enable all the things that hardware
needs.

In contrast, asking people "do you need support for ABC?" when they
don't know what ABC is is _not_ helpful.

IOW, when you write Kconfig entries, your rules should be:

 - NOTHING is ever enabled by default, unless it's an old feature that
was enabled before and got split out (so that "make oldconfig" gives a
working kernel)

 - you NEVER ask questions that normal people can't answer.

For example, we have *way* too many questions that come about because
some developer went "I don't know what the answer is, I'll just make
it a Kconfig option". And I absolutely *HATE* those questions. Dammit,
if the developer doesn't know, then a user sure as hell doesn't
either.

I tend to keep on harping on Kconfig issues, because I really do think
that it's one of the biggest hurdles for normal users to just build
their own kernels. We make the rest of the build system pretty damn
simple, with a simple "make" and then as root "make modules_install
install".

But the Kconfig phase is a complete disaster, and it's because kernel
developers don't seem to think about users.

              Linus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ