linux-kernel - Re: [GIT PULL] turbostat 2024.04.10

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: <CAHk-=wgNZV3pwPMjOr1_NGUt3L1rK+38xtSp78w02X6qYwqhJA@mail.gmail.com>
Date: Thu, 11 Apr 2024 12:14:30 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Len Brown <lenb@...nel.org>
Cc: Linux PM list <linux-pm@...r.kernel.org>, 
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] turbostat 2024.04.10

On Thu, 11 Apr 2024 at 11:20, Len Brown <lenb@...nel.org> wrote:
>
> ISTR that once upon a time at the kernel summit you expressed a
> preference that things like utilities (which sometimes depend on merge
> window changes) come in after rc1 is declared to basically stay out of
> the way.

That may have been true at some point, but probably long ago - the
merge windows have been so reliable that it's just not an issue any
more.

So I'd rather see people hold to the normal release cycle, and aim to
have the rc releases for fixes or major problems.

We also used to allow entirely new drivers etc outside the release
cycle as a "this cannot regress" exception to the normal rules, but
that has also been largely abandoned as the release cycle is just
short enough that it makes no sense.

So the "new hardware support" rule has basically been watered down
over the years, and has become a "new hardware IDs are fine" kind of
rule, where just adding basically just a PCI ID or OF matching entry
or similar is still fine, but no more "whole new drivers".

                  Linus