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.
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.
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.
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...
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.
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...
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).
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....
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.:
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..
http://kroah.com/log/blog/2016/09/06/4-dot-9-equals-equals-n...