Language Selection

English French German Italian Portuguese Spanish

Linux 3.17-rc5

Filed under
Linux

So I should probably have delayed this until Wednesday for sentimental
reasons: that will be 23 years since I uploaded the 0.01 source tree.
But I'm not an overly sentimental person, so screw that. I'm doing my
normal Sunday release.

And as I mentioned in the rc4 notes, the previous rc was pretty small,
possibly because neither Greg nor Davem had sent in any updates that
week. Guess what? David's networking updates came in an hour after I
did rc4, and sure enough Greg came in this week too, so - surprise
surprise - rc5 isn't as small as rc4 was.

Oh well. It was too good to last.

I also got a report of an *old* performance regression in the dentry
cache (since 3.10 - positively ancient), and that in turn made me look
around some more, and there were a few other special cases that could
cause us to not do as well as we should. I fixed some of it, and Al
fixed the rest. So hopefully we not only fixed the reported
regression, but are actually doing better than we used to.

Anyway, the size of rc5 means that I'm certainly not cutting the
release early, which means that I will have to think about exactly
what I will do about the next merge window. Because it looks like it
might end up conflicting with my travel around LinuxCon EU. I haven't
quite decided what I'll do - I might release 3.17 normally, but then
just not open the merge window due to travel. Or, if there are more
issues than I think there will be, maybe I'll delay the 3.17 release.

We'll see.

Regardless - the rc5 changes is about half drivers (networking, gpu,
usb, input, ata..) with the rest being mostly a mix of filesystem
updates (the aforementioned performance thing in the core vfs layer,
but also some NFS export issues found by Al and misc other stuff),
architecture updates (arm, parisc, s390) and core networking. And a
smattering of other. Shortlog appended.

In other words, things look fairly normal, even if I'd have been
happier with rc5 being smaller. But with the bump from networking and
drivers, I'm not going to claim that this was either unexpected or
particularly scary. I'm hoping we're done now, and that rc6 and rc7
will be noticeably calmer.

Knock wood.

Linus

Read more

More in Tux Machines

Testing Slax 10.2 beta1

Changes include disabling apparmor, which was preventing some programs from starting properly (eg. man), and fixing chromium by installing chromium-sandbox package. Also added was dummy 'sudo' command (so you can copy&paste sudo commands from internet and it will work as long as you are signed in as root). I will be happy if you let me know problems you encounter, either by email, or using slax-users google group, or by commenting to this blog post. Read more

GCC: OpenMP / OpenACC and Static Analysis Framework

  • The GCC 10 Compiler Lands OpenMP / OpenACC Offloading To AMD Radeon GPUs

    A few days ago I wrote about the OpenMP / OpenACC offloading patches for Radeon "GCN" GPUs being posted and seeking inclusion in the GCC 10 compiler that will be released in a few months. Those patches were successfully merged meaning this next annual update to the GNU Compiler Collection will feature initial OpenMP/OpenACC code offloading support to supported AMD GPU targets. After GCC 9 only had the initial AMD Radeon GCN target in place, GCC 10 in early 2020 will feature the initial offloading support using the modern OpenMP and OpenACC APIs, thanks to the merges this week. The libgomp port and associated bits for the AMD GCN back-end have landed thanks to the work done by Code Sourcery under contract with AMD.

  • RFC: Add a static analysis framework to GCC
    This patch kit introduces a static analysis pass for GCC that can diagnose
    various kinds of problems in C code at compile-time (e.g. double-free,
    use-after-free, etc).
    
    The analyzer runs as an IPA pass on the gimple SSA representation.
    It associates state machines with data, with transitions at certain
    statements and edges.  It finds "interesting" interprocedural paths
    through the user's code, in which bogus state transitions happen.
    
    For example, given:
    
       free (ptr);
       free (ptr);
    
    at the first call, "ptr" transitions to the "freed" state, and
    at the second call the analyzer complains, since "ptr" is already in
    the "freed" state (unless "ptr" is NULL, in which case it stays in
    the NULL state for both calls).
    
    Specific state machines include:
    - a checker for malloc/free, for detecting double-free, resource leaks,
      use-after-free, etc (sm-malloc.cc), and
    - a checker for stdio's FILE stream API (sm-file.cc)
    
    There are also two state-machine-based checkers that are just
    proof-of-concept at this stage:
    - a checker for tracking exposure of sensitive data (e.g.
      writing passwords to log files aka CWE-532), and
    - a checker for tracking "taint", where data potentially under an
      attacker's control is used without sanitization for things like
      array indices (CWE-129).
    
    There's a separation between the state machines and the analysis
    engine, so it ought to be relatively easy to add new warnings.
    
    For any given diagnostic emitted by a state machine, the analysis engine
    generates the simplest feasible interprocedural path of control flow for
    triggering the diagnostic.
    
  • GCC Might Finally Have A Static Analysis Framework Thanks To Red Hat

    Clang's static analyzer has become quite popular with developers for C/C++ static analysis of code while now the GNU Compiler Collection (GCC) might finally see a mainline option thanks to Red Hat. Red Hat's David Malcolm has proposed a set of 49 patches that appear to be fairly robust and the most we have seen out of GCC static analysis capabilities to date.

Reports From KDE Development and Lakademy 2019

  • This week in KDE: touchy and scrolly and GTK-ey and iconey

    There are some neat things to report and I think you will enjoy them! In particular, I think folks are really going to like the improvements to GNOME/GTK app integration and two sets of touch- and scrolling-related improvements to Okular and the Kickoff Application Launcher, detailed below:

  • KDE Plasma 5.18 Bringing Better GTK/GNOME App Integration

    Aside from tightening the GNOME/GTK integration with KDE, this week there has also been some Okular improvements, better touch support for the Kickoff Application Launcher, deleting files within the Dolphin file manager now uses a separate worker thread for the I/O, Spectacle can now integrate with OBS Studio as a new screen recording option, and other enhancements.

  • Lakademy 2019

    I’m now writing this post in the last hours of the Lakademy 2019 (and my first one). It was really good to be “formally” introduced to the community and it’s people, and to be in this environment of people wanting to collaborate to something as incredible as KDE. Althought I wanted to contribute more to other projects, I did some changes and fixes in the rocs, wrote my Season of KDE project and got some tasks that can help with the future of rocs.

today's howtos