@kernellogger But what if that “crazy” operation is actually documented in a man page?
# cp -r /sys/kernel/tracing/events /tmp/tracing
$ trace-cmd sqlhist -t /tmp/tracing ...
Doing some testing against a change; I ran two traces. Recording the trace before applying the patch as
trace-b.dat and then calling the trace file after applying the patch as
trace-a.dat. Then doing an
ls trace*.dat I have:
And it looks like
trace-a.dat should come before
trace-b.dat. I’m so confused! 😛
I’m being “schooled” by Al Viro on how dcache, inodes, and files work internally.
This is a very interesting read that I recommend anyone that wants to understand VFS better should look at.
And don’t just stop at that email, the thread goes on. Very educational. Hopefully someone smarter than I can add this to the VFS documentation in the kernel 😉
@gregkh @vbabka @qyousef Well the problem is that it still requires manual effort to even include the clean up patch. The point I was making is that if a clean up patch causes a backport to fail, I still have to look at why instead of it just nicely being pulled in by the stable tag. The clean up in question, touched much more than the areas that failed, so it too may not backport properly.
@qyousef @vbabka Exactly. If you do clean ups in the code that you are modifying then all is OK, because the modifications you are making will cause the backports to fail anyway, so the clean ups do not cause extra work. But if you just have random clean ups in code that hasn’t changed in years, if a bug in that code is found, then the backports are going to be a pain fixing all previous version before the “cleanup”.
false better than 0 is more for understanding that the value is a boolean an not to be taken as numeric. Sometimes that makes it easier to understand the logic. I’ve been trying to use boolean in those cases as well. This also is a requirement if you ever plan on using Rust 😉
I don’t mind clean up patches, but this is the reason a lot of Linux kernel maintainers frown on them.
This failure is because of a clean up patch that converted everything to “bool” where it could be:
If I had not accepted that clean up, this backport would have been pulled in automatically with no extra work from myself. But because I added that clean up, I now have to fix this for every stable release before that clean up 🙁
ktest.pl already does this!
Thank you Masayoshi Mizuma! You only added this feature back in 2019 🤪
Except, it looks like it overwrote the default kernel, making my machine not able to boot the normal kernel. Had to play magic to get it back booting again.
Grub2 tries to make it so easy that it makes it suck for simply things.
@oleksandr I have several test boxes that have various boot loaders. This one I haven’t touched in a while, and is the first time I noticed it. It seems to be the default for Fedora (which I’m a Debian guy). I need to get it to work for
ktest.pl anyway, as others may need it.
OK, finally fixed it with:
grubby --add-kernel=/boot/vmlinuz-test --initrd=/boot/initramfs-test.img --title 'Test Kernel'
But now I have to figure out how to have ktest read this shit and know which option to set
I really hate
grub2. Now they hide the menu entries in a separate directory. This really makes it difficult when testing kernels and adding tweaks to the command line. It now doesn’t seem to find my test kernel and I have no idea how to make it do so. 😠