@exi @kernellogger We will finally get to relax at that time. Or at least we can look forward to the potential to relax, providing us hope when buried neck-deep in stable backports...

@vegard @kernellogger Ah, so back in February we made it 4 years, not 2, so why did everyone freak out a month ago thinking it was going to be 2 years?

Math with dates is hard :)

@kernellogger Yes, that's why the dates are like this.

And I just realized, we never publicly said anything about "2 years support for LTS", the kernel.org page has always had longer dates, all we said was "we will not be doing 6 years anymore".

So no one actually looks at the documentation we write (i.e. the web page), AND I didn't even remember that we had written that back in February of this year, this feels like a "write once, read never" type of file...

So many truths are hidden,
So many facts untold,
Queries left unbidden,
Concealed below the fold.

My head droops to the table,
But I must remain informed:
"Is the kernel stable?"
"How is babby formed?"

RFC for the replacing the Linux kernel #Android #Binder driver with a fully functional #Rust version:

https://lore.kernel.org/lkml/20231101-rust-binder-v1-0-08ba9197f637@google.com/

All the talks from Embedded Recipes 2023 are now online, including "The TTY Layer: the Past, Present, and Future" by @gregkh https://www.youtube.com/watch?v=g4sZUBS57OQ&list=PLwnbCeeZfQ_Mi7gjUpLZxXGOcEBS_K8kH&index=5 #er2023

@davidrevoy @standingpad Use email, that's how the kernel is developed and how bugs are reported, send it to the author of that commit and the mailing list listed in the MAINTAINERS file for the subsystem.

No need to file some ticket in some random web form with some odd account, email. It's simple, and easy (note, turn off HTML mode for it please.)

Good luck!

@jani The DCO does cover it, it is just that people don't seem to actually understand where the information from these "AI" tools is coming from for some reason...

This came up in a private thread about a kernel patch review where the contents were created with an "AI" tool, so I figured I might as well put it somewhere a bit more public as people don't seem to really understand the issues involved:

My policy is that I do not take any output of any "AI" tools unless the providence of the data that was used to feed the AI tool can be proven to be under the proper copyright rules as to be compatible with the GPLv2 license.

So in other words, nothing from chatgpt at all, that's obviously full of copyrighted works that are not allowed to be reused in this manner.

@stefanct @kernellogger @LWN We'll figure it out eventually, give us some time :)

#Linux #kernel 6.6 is out: https://lore.kernel.org/all/CAHk-=wiZuU984NWVgP4snp8sEt4Ux5Mp_pxAN5MNV9VpcGUo+A@mail.gmail.com/

"""So this last week has been pretty calm, and I have absolutely no excuses to delay the v6.6 release any more, so here it is. […] Linus"""

For an overview of new features, check out the two #LinuxKernel 6.6 merge window articles from @LWN or the Kernelnewbies summary:

https://lwn.net/Articles/942954/ and https://lwn.net/Articles/943245/

https://kernelnewbies.org/Linux_6.6

@kernellogger @LWN It's on the front page now, took a bit for the signed tag to propagate due to timezone differences...

@jarkko @conor drivers/staging/ is for code that is abandoned by companies and the community needs others to clean/fix it up, it is not for "code just not ready to be merged yet" as it ends up taking more work to get code out of staging into the real part of the kernel than to just do the real work to start with out-of-tree and then submit it to the proper location.

In other words, drivers/staging/ is not a dumping ground for experiments :)

Just do it right, and get it merged upstream correctly.

And why 5.19? That's a long obsolete and insecure kernel version, no one should ever still be using that mess, especially anything purporting to have anything to do with "security" in any form.

Not a tragedy: "The greatest value that #opensource foundations bring is the creation of a neutral collaboration hub for everyone participating in, and taking a dependency on, a project."

https://www.linuxfoundation.org/blog/how-open-source-foundations-protect-the-licensing-integrity-of-open-source-projects

https://www.centerforcybersecuritypolicy.org/insights-and-research/joint-letter-of-experts-on-cra-and-vulnerability-disclosure A good letter to the EU governments about why the CRA isn't going to be good for vulnerability disclosure as-written. It's nice to see this portion of the CRA finally getting some exposure.

TIL there is an ISO standard for security vulnerability disclosure. First version was made final in 2014, latest version in 2018. Despite actually working in this area for 20+ years, I only now hear of this, yet can't actually see it due to crazy ISO document rules {sigh}
https://www.iso.org/standard/72311.html

@vegard @kernellogger very cool!

@kernellogger oops, I should have read that in the script, my fault, thanks!

@kernellogger Let's debug by this horrible interface!

$ ./linuxscru history Makefile

Traceback (most recent call last):
File "/mnt/fast_t2/linux/gregkh/./linuxscru", line 526, in <module>
cmdargs.func(cmdargs)
File "/mnt/fast_t2/linux/gregkh/./linuxscru", line 376, in cmd_history
if not GITTREE.is_file(cmdargs.patterns):
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/mnt/fast_t2/linux/gregkh/./linuxscru", line 251, in is_file
if GITTREE.gitpyrepo.git.rev_list('-1', GITTREE.remotes['mainline'][0], '--', pattern):
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.11/site-packages/git/cmd.py", line 739, in <lambda>
return lambda *args, **kwargs: self._call_process(name, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.11/site-packages/git/cmd.py", line 1315, in _call_process
return self.execute(call, **exec_kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.11/site-packages/git/cmd.py", line 1110, in execute
raise GitCommandError(redacted_command, status, stderr_value, stdout_value)
git.exc.GitCommandError: Cmd('git') failed due to: exit code(128)
cmdline: git rev-list -1 mainline/master -- Makefile
stderr: 'fatal: bad revision 'mainline/master''

@kernellogger And the obligatory `perf stat` output:

$ perf stat ~/linux/stable/commit_tree/id_found_in 27e348b221f6
6.3 6.3.2

Performance counter stats for '/home/gregkh/linux/stable/commit_tree/id_found_in 27e348b221f6':

927.17 msec task-clock:u # 2.695 CPUs utilized
0 context-switches:u # 0.000 /sec
0 cpu-migrations:u # 0.000 /sec
102,368 page-faults:u # 110.409 K/sec
625,620,707 cycles:u # 0.675 GHz (86.75%)
17,593,408 stalled-cycles-frontend:u # 2.81% frontend cycles idle (74.93%)
244,430,441 stalled-cycles-backend:u # 39.07% backend cycles idle (77.20%)
1,688,567,927 instructions:u # 2.70 insn per cycle
# 0.14 stalled cycles per insn (79.87%)
281,869,777 branches:u # 304.009 M/sec (90.53%)
2,038,670 branch-misses:u # 0.72% of all branches (94.14%)

0.343984835 seconds time elapsed

0.198861000 seconds user
0.661305000 seconds sys