The amount of times the word "updates" appears in the commits makes me feel much better at my difficulty of choosing succinct and unique commit messages.
Note that those aren't "change commits", but merge commits aggregating large swathes of other changes. And it's not even all merge commits, it's just the merges from Linus' "top lieutenants".
But I sympathize. I often spend more time on commit messages than the actual changes...
It was a fix in PCI error handling on powerpc for a reasonably rare situation where the PCI card doesn't successfully come back up after we reset the slot or the PCI controller...
Writing long commit messages (especially for internal/private projects) often gives me a slightly forlorn feeling, knowing that these words will almost certainly never be read again by another person, and possibly even I might never see them again. I persist only because when they do get read, they can be absolutely invaluable in explaining what on earth I was thinking at the time.
I really am thankful that you do write long commit messages. As a student starting out in OSS, I have had to track down why the particular piece of code is written like it and I go hunting down git blame and that really helps me. I also follow the practice when I can and hope that it helps future contributors or maintainers.
I picked some of the longer ones on the first page just for contrast with your impression, many have shorter commit messages, but they all have a commit message with some explanation.
DRM in the context of the Linux kernel refers to the Direct Rendering Manager, a graphics component. If you want to see all the merge commits from Dave Airlie (the long descriptions of which include a list of commits), try https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....
Intel memory protection key support is nice. QEMU now also has support for emulation of pkeys, but naturally you can't use them with KVM/hw acceleration (because you don't have hardware to support them). This is generally enough for testing/designing, though. (The performance of memory protection keys will be important however, so it's not helpful to really determine that yet.)
That said, I'd suggest obviously building your own minimal kernel/chroot to do these tests, since the lack of KVM/available hardware makes emulation turn-around time fairly terrible for right now.
There's already a patch (due for 4.10) to detect and warn about this silliness. Since the Intel guy says that all the systems that shipped with this mode now have firmware updates to allow disabling it, there's very little reason for anyone to implement full support.
Hopefully in the future Intel will think twice before implementing ugly firmware-level hacks to aid in working around limitations of Microsoft's driver stack.
That's the firmware setting that disables the hack that hides NVMe devices behind the chipset's AHCI controller. Aside from making it possible for standards-compliant NVMe drivers to function as expected, not lying to the OS about the hardware topology also allows the OS to access the PCI configuration space (allowing for eg. ASPM support) and not unnecessarily share interrupts between two entirely separate devices.
If it served a useful purpose in the first place, yes. And if it were properly documented and didn't cripple certain areas of functionality (and probably hurt performance a bit, but I don't yet have a system to measure this with).
kernel 4.9 is the first kernel with full dynamic tracing support built in (beyond the power of systemtap, etc) . We are soon going to see tools like dtrace being built right for Linux.
Im excited for thw future of application development and monitoring on Linux. Imagine a whole bunch of tools more powerful than NewRelic.
Interesting, I assume you're referring to some extension of eBPF that happened in the 4.9 pulls. AFAIK eBPF already is pretty functional in 4.8. What got added that allows full dynamic tracing? (And what is full dynamic tracing?).
> Timed sampling was the final major piece, and it landed in Linux 4.9-rc1 (patchset). Many thanks to Alexei Starovoitov (now working on BPF at Facebook), the lead developer behind these BPF enhancements.
This is indeed something possible with DTrace that was difficult (or not very efficient) to do with eBPF before. I assume one could've hooked into one of the kernel interrupt/... functions and used that as a ghetto timer, but the gymastics to convert that to real time might've been daunting.
Linus provided a TL;DR: A bit over two
thirds drivers (staging, GPU and networking are the bulk of it, but it's all over), with the rest looking fairly normal too: arch updates, documentation, generic networking, filesystems..
The problem, as I understand it, is that these are summaries of summaries. The actual commit messages are incredibly detailed, then they get rolled up by the lieutenants into a single merge with one line per change, then Linus merges them in and adds to the final summary 'networking updates'. If you want to know what actually changed, then look at the commit logs, e.g.:
51 comments
[ 5.2 ms ] story [ 134 ms ] threadBut I sympathize. I often spend more time on commit messages than the actual changes...
My worst commit-message-to-code-changed ratio is a commit in the kernel with a 1307 char/175 word commit message, and a single character change...
Link for the curious?
https://github.com/torvalds/linux/commit/949e9b827eb4736d96d...
I wish I could upvote this more than once.
full list: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.... (very "slow" at the very end of the development cycle)
example merge: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....
example commit: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....
I picked some of the longer ones on the first page just for contrast with your impression, many have shorter commit messages, but they all have a commit message with some explanation.
A few days ago the author those changes are listed under (Dave Airlie) was on the HN frontpage for his comments on an AMD RFC[1].
[0] https://en.wikipedia.org/wiki/Direct_Rendering_Manager
[1] https://news.ycombinator.com/item?id=13136426
https://en.wikipedia.org/wiki/Direct_Rendering_Manager
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...
That said, I'd suggest obviously building your own minimal kernel/chroot to do these tests, since the lack of KVM/available hardware makes emulation turn-around time fairly terrible for right now.
http://kroah.com/log/blog/2016/09/06/4-dot-9-equals-equals-n...
Hopefully in the future Intel will think twice before implementing ugly firmware-level hacks to aid in working around limitations of Microsoft's driver stack.
Not sure why it wasn't copied to the wiki, maybe because of
> Warning: /!\ /!\ The changelog is not complete. It will be available during the next week.
Im excited for thw future of application development and monitoring on Linux. Imagine a whole bunch of tools more powerful than NewRelic.
EDIT: Parent is probably referring to something mentioned here: http://www.brendangregg.com/blog/2016-10-27/dtrace-for-linux.... Apparently timed sampling got added, I quote Brendan:
> Timed sampling was the final major piece, and it landed in Linux 4.9-rc1 (patchset). Many thanks to Alexei Starovoitov (now working on BPF at Facebook), the lead developer behind these BPF enhancements.
This is indeed something possible with DTrace that was difficult (or not very efficient) to do with eBPF before. I assume one could've hooked into one of the kernel interrupt/... functions and used that as a ghetto timer, but the gymastics to convert that to real time might've been daunting.
There is also a lot of good research going on in the "Make Wi-Fi Fast" project. See https://www.bufferbloat.net/projects/make-wifi-fast/wiki/
For concrete results, see June 2016 paper: "Fixing the WiFi Performance Anomaly" at https://blog.tohojo.dk/2016/06/fixing-the-wifi-performance-a...
Read the archives of the "Make-wifi-fast" mailing list at: https://lists.bufferbloat.net/listinfo/make-wifi-fast
If you want to use bleeding edge LEDE code (spinoff of OpenWrt) to see if your Wi-Fi is faster than mine, try: https://kau.toke.dk/lede/airtime-fairness-builds/ar71xx/gene...
Get your lag down to milliseconds no matter how you load your network.
https://github.com/torvalds/linux/compare/v4.9-rc8...v4.9