dcsimg
Linux Today: Linux News On Internet Time.




More on LinuxToday


Linux 5.6 rc1

Feb 10, 2020, 19:00 (0 Talkback[s])
(Other stories by Linus Torvalds)
The rc1 tag has been pushed out, and so the merge window for 5.6 is closed.

This was actually a slightly smaller merge window than usual, but I
think that what happened is simply that the holiday season impacted
new development. It impacted the 5.5 rc series less than I had
expected, but seems to instead have caused 5.6 to have slightly less
development than normal.

Of course, "slightly less" is just that - we still have more than 10k
commits (11.5k if you count merges too). So it's not like it's tiny,
and it's still _way_ too big to post full shortlogs or anything like
that. So below is my usual "mergelog" that shows my merges and who
they came from.

And as always, note that my merge log shows who I merged from, which
is not necessarily at all who developed the code. There's more than
1400 individual developers in there, and I always feel a bit bad by
just grouping things by top-level maintainer, but I've never found a
good way to summarize the merge window development by author (like the
rc shortlogs are done). So I just keep mentioning this, to make it
clear that this shows just _one_ side of the credits for getting code
merged.

Apart from being slightly smaller than usual, the stats all look
fairly normal. About two thirds of the patch is drivers (and it's all
over, but gpu and networking dominate as usual), with the rest being
the usual mix of arch updates, documentation, filesystem updates,
networking, tooling, and just misc core kernel updates. And none of
that is in the least surprising or unusual.

From an actual ABI perspective, I guess the openat2() support by
Aleksa might be worth mentioning - it's been in development for a long
time, and went through several revisions on the mailing lists. It's
seldom we end up adding some new interfaces to really core stuff, but
this makes it much easier to do some path resolution control in user
space - particularly for sandboxing, You can ask to do filename lookup
without following symlinks, for example, or not following mountpoints.
So it's much easier to write code that says "I have this untrusted
pathname that I want to open - only open it if it doesn't jump out of
my sandboxed area".

But otherwise it all looks fairly normal. A couple of new specialty
filesystems if you're into that kind of thing, you can see the big
picture in the merge log below.

Go forth and test,

Complete Story

Related Stories: