I love how vibecoded commits are called vommits. It's so perfect.

I should also say that the code is much more complex than what it was back then.

@notbobbytables The reason for this option, is that ktest.pl can take a MIN_CONIFG option where you pass the minimal config options that allow your box to boot. This is useful, because you can take someone else’s config (that you may need to debug), use that to build, and ktest.pl will add your min conifg on top, to make sure your box will build.

Now you have a kernel that is as close to possible as the kernel of the person that sent you their config. This is extremely useful when you need to debug their environment.

@notbobbytables You should check out ktest.pl’s make_min_config option. If you have ktest.pl set up, this option will have ktest “bisect” a bunch of configs until it gives you minimal config that boots the board (and optionally runs a test). At the end of the test, if you disable any config, it will not boot.

@ljs I can’t wait to see you on “flying pig airlines!”

21 years ago today, I posted streamline_config.pl.

Which most of you now know it as make localmodconfig.

I thought this was the appropriate shirt to wear to my colonoscopy today.

trace-cmd 3.4 has been released!

What’s new? The biggest change is that if you record with function or function graph tracer and enable the func-args or funcgraph-args then trace-cmd will save the BTF file (/sys/kernel/btf/vmlinux) in the trace.dat and use it for trace-cmd report to show the functions:

 function:             mutex_unlock(lock=0xffffffff831dbbe0)
 function:             __mutex_unlock_slowpath(lock=0xffffffff831dbbe0, ip=0xffffffff814a7154)
 function:             __f_unlock_pos(f=0xffff8881538de000)
 function:             mutex_unlock(lock=0xffff8881538de090)
 function:             __mutex_unlock_slowpath(lock=0xffff8881538de090, ip=0xffffffff816e8ed1)
 function:             mem_cgroup_handle_over_high(gfp_mask=0xcc0)

Also, if you run trace-cmd extract on a persistent ring buffer, it will save the last_boot_info file (and /proc/modules) and use it to properly calculate the addresses of the functions from the previous boot to the addresses of the same functions of the current boot so that it can properly get their names from the saved kallsyms. This way you can even see all the functions that did the reboot!

boot_mapped:            <...>-1     [000] d..1.  6869.910269: function:             native_machine_emergency_restart()
boot_mapped:            <...>-1     [000] d..1.  6869.910269: function:                tboot_shutdown(shutdown_type=0x0)
boot_mapped:            <...>-1     [000] d..1.  6869.910269: function:                machine_real_restart(type=0x0)
boot_mapped:            <...>-1     [000] d..1.  6869.910269: function:                   _raw_spin_lock(lock=0xffffffff95d03214)
boot_mapped:            <...>-1     [000] d..2.  6869.910269: function:                   rtc_cmos_write(val=0x0, addr=0x8f)
boot_mapped:            <...>-1     [000] d..2.  6869.910276: function:                   _raw_spin_unlock(lock=0xffffffff95d03214)
boot_mapped:            <...>-1     [000] d..1.  6869.910277: function:                   load_trampoline_pgtable()
boot_mapped:            <...>-1     [000] d..1.  6869.910277: function:                   __flush_tlb_all()
boot_mapped:            <...>-1     [000] d..1.  6869.910278: function:                      native_flush_tlb_global()

libtraceevent 1.9 has been released!

What’s new? Support for loading BTF and printing function arguments. Also, processing of the persistent ring buffer. It adds APIs to be able to map the function addresses from the previous boot to address of the current boot so that their names can be found from kallsyms.

@vbabka @DesnoyersMa I’ve sent Linus default y configs before. But I always mention “this keeps previous behavior”. What gets him pissed off is when you send a default y for a new feature. If it’s something that doesn’t change his config, he hasn’t complained to me about it before.

@DesnoyersMa The default needs to keep how it is today the same. For hiding, it would be default N.

@DesnoyersMa I would actually make it CONFIG_HIDE_TRACE_PRINTK to allow those that don't want it included to be able to have that option. As right now it's something people want that build their kernels.

I’m fighting to keep trace_printk.h in kernel.h. If you use trace_printk() for debugging, and do not want to have to add:

#include <linux/trace_printk.h>

to every file you you want to add a trace_printk() to, please make yourself heard and respond to this email thread.

Otherwise, trace_printk() will become a bit more tedious to use.

https://lore.kernel.org/all/20251229111748.3ba66311@gandalf.local.home/

I’ve once again compiled my server and workstation with the branch profilers enabled. You can see the data for my server here

The branch_annotated file is where “likely”() and “unlikely()” are correct or not.

The branch_all is if the if statement was true or false.

The data is updated nightly on a live machine. I’ll run his for a couple of weeks to see where the Linux kernel gets it wrong.

The currently running version is v6.18.2.

@cyberia @torvalds It is a shame. I love “right to modify” and “right to repair”, but honestly, GPLv2 does not have a clause about the device itself. It’s only about the software. If the device requires keys and such to run, the GPLv2 says nothing about allowing it to run.

It’s not about what we want the license to mean (although Torvalds has the right to state his intent), it is also about what the license actually says. The judge mentioned:

If this was the intent of the Agreements, the Agreements could have been readily modified to state that users must be permitted to modify and reinstall modified software on products which use the program while ensuring the products continue to function.

The GPLv2 is a little ambiguous with the install scripts, and the judge is saying that due to that ambiguity, it does not cover reinstalling on devices. If it did, then the “agreement” (the GPLv2 license) should explicitly state so.

@MichaelOpdenacker @fosdem @openembedded

Good luck on your talks. I won’t be going. There’s a comedian coming to my home town that weekend and I booked tickets fro my wife and myself. She’d be pissed if I left for a conference instead. Maybe next time!

@codonell BTW, the wait list has a priority order where people who have submitted content gets first dibs. Did you submit to the Toolchain MC?

Linux Plumbers in-person tickets are sold out! But you can still add yourself to the wait-list. Read the blog for more details. https://lpc.events/blog/current/index.php/2025/09/19/in-person-registration-is-sold-out-2/

Linux Plumbers 2025 in Tokyo’s Call for Proposals is nearing its end! https://lpc.events/blog/current/index.php/2025/09/08/the-call-for-proposals-is-nearing-its-end/

@itaru Of course it is. It’s part of our tradition!