Linux 4.20-rc1
From: Linus Torvalds
Date: Sun Nov 04 2018 - 19:13:21 EST
So I did debate calling it 5.0, but if we all help each other, I'm
sure we can count to 20. It's a nice round number, and I didn't want
to make a pattern of it. I think 5.0 happens next year, because then I
*really* run out of fingers and toes.
Anyway, 4.20-rc1 is tagged and pushed out, and the merge window is
over. This was a fairly big merge window, but it didn't break any
records, just solid. And things look pretty regular, with about 70% of
the patch is driver updates (gpu drivers are looming large as usual,
but there's changes all over). The rest is arch updates (x86, arm64,
arm, powerpc and the new C-SKY architecture), header files,
networking, core mm and kernel, and tooling.
In fact, tooling is quite noticeable. A fair amount of selftest
changes, but also various perf tooling updates.
There's a vfs pull request I declined and it might still go in later
in a slightly reduced form, but apart from that I think everything got
merged. We had one pull request that almost missed the merge windows
due to a silly change in my email setup, but I verified that nothing
else had happened to hit that special case.
One thing I _would_ like to point out as the merge window closes: I
tend to delay some pull requests that I want to take a closer look at
until the second week of the merge window when things are calming
down, and that _really_ means that I'd like to get all the normal pull
requests in the first week of the two-week merge window. And most
people really followed that, but by Wednesday this week I had gotten a
big frustrated that I kept getting new pull requests when I wanted to
really just spend most of the day looking through the ones that
deserved a bit of extra attention.
And yes, people generally kind of know about this and I really do get
*most* pull requests early. But I'm considering trying to make that a
more explicit rule that I will literally stop taking new pull requests
some time during the second week unless you have a good reason for why
it was delayed.
Because yes, the merge window is two weeks, but it's two weeks partly
exactly _because_ people (not just me) sometimes need extra time to
resolve any possible issues, not because regular everyday pull
requests should spread out over the whole two weeks. The development
for things meant for the next release should have been done by the
time the merge window opens.
Anyway, let's see. Maybe it won't be needed. It hasn't become a
problem, it just was starting to feel a bit tight there.
Oh, and I did try to do the reply emails. And I'm _entirely_ sure that
I must have missed acknowledging emails for a few pull requests. I'm
hoping that by the time the next merge window rolls around, we'll just
have new automation for it, so that everybody just automatically gets
notified when their pull request hit mainline. In the meantime, you
have a good chance - but not a guarantee - that I'll send a "Pulled"
ack email when I start processing a pull request.
And as usual for rc1, the log below is just the list of people I
pulled from with a one-liner "mergelog". Very much a high-level
summary of merges, for details you need to look into the git tree..
Linus
---
Al Viro (8):
tty ioctl updates
vfs fixes
compat_ioctl fixes
alpha syscall glue updates
more ->lookup() cleanups
AFS updates
misc vfs updates
9p fix
Alex Williamson (1):
VFIO updates
Alexandre Belloni (1):
RTC updates
Andrew Morton (3):
updates
more updates
more updates
Arnd Bergmann (4):
ARM SoC device tree updates
ARM SoC defconfig updates
ARM SoC driver updates
ARM SoC platform updates
Bartlomiej Zolnierkiewicz (1):
fbdev updates
Benson Leung (1):
chrome-platform updates
Bjorn Andersson (2):
remoteproc updates
rpmsg updates
Bjorn Helgaas (1):
PCI updates
Bob Peterson (1):
gfs2 updates
Boris Brezillon (1):
mtd updates
Borislav Petkov (2):
EDAC updates
more EDAC updates
Bruce Fields (1):
nfsd updates
Catalin Marinas (2):
arm64 updates
more arm64 updates
Christoph Hellwig (3):
dma mapping updates
more dma-mapping updates
dma-mapping fix
Corey Minyard (1):
IPMI updates
Dan Williams (1):
libnvdimm updates
Darren Hart (1):
x86 platform driver updates
Dave Airlie (2):
drm updates
drm fixes
Dave Chinner (1):
vfs dedup fixes
David Kleikamp (1):
jfs updates
David Miller (8):
sparc updates
networking updates
sparc fix
sparc fixes
networking fixes
networking fixes
sparc fixes
networking fixes
David Sterba (2):
btrfs updates
more btrfs updates
Dennis Zhou (1):
percpu fixes
Dmitry Torokhov (1):
input updates
Dominik Brodowski (1):
pcmcia fixes
Dominique Martinet (1):
9p updates
Eduardo Valentin (1):
thermal SoC updates
Eric Biederman (1):
siginfo updates
Geert Uytterhoeven (1):
m68k updates
Greg KH (5):
USB/PHY updates
driver core updates
char/misc driver updates
staging/IIO driver updates
tty/serial updates
Greg Ungerer (1):
m68k nommu fix
Guenter Roeck (1):
hwmon updates
Guo Ren (2):
C-SKY architecture port
csky dtb fixups
Helge Deller (2):
parisc updates
parisc updates
Herbert Xu (1):
crypto updates
Ilya Dryomov (1):
ceph updates
Ingo Molnar (22):
RCU updates
EFI updates
locking and misc x86 updates
perf updates
RAS updates
scheduler updates
x86 apic updates
x86 asm updates
x86 boot updates
x86 build update
x86 cpu updates
x86 grub2 updates
x86 hyperv updates
x86 mm updates
x86 paravirt updates
x86 platform updates
x86 pti updates
x86 vdso updates
irq fixes
perf updates and fixes
x86 fixes
scheduler fixes
Jacek Anaszewski (2):
LED updates
LED fix
Jaegeuk Kim (1):
f2fs updates
James Bottomley (2):
SCSI updates
more SCSI updates
James Morris (6):
security subsystem updates
integrity updates
TPM updates
smack updates
LoadPin updates
keys updates
Jan Kara (2):
fsnotify updates
ext2 and udf updates
Jason Gunthorpe (1):
rdma updates
Jassi Brar (1):
mailbox updates
Jens Axboe (4):
block layer updates
libata updates
more block layer updates
block layer fixes
Jiri Kosina (1):
HID updates
Joerg Roedel (1):
IOMMU updates
John Johansen (1):
apparmor updates
Jon Mason (1):
NTB updates
Jonathan Corbet (1):
documentation updates
Juergen Gross (1):
xen fixes
Kees Cook (3):
pstore updates
VLA removal
stackleak gcc plugin
Konrad Rzeszutek Wilk (1):
xen swiotlb fix
Lee Jones (2):
MFD updates
backlight updates
Linus Walleij (2):
pin control updates
GPIO updates
Mark Brown (3):
regmap updates
spi updates
regulator updates
Mark Salter (1):
c6x update
Martin Schwidefsky (1):
s390 updates
Masahiro Yamada (2):
Kbuild updates
Kbuild updates
Matthew Wilcox (1):
XArray conversion
Mauro Carvalho Chehab (2):
media updates
new experimental media request API
Max Filippov (1):
Xtensa fixes and cleanups
Michael Ellerman (2):
powerpc updates
powerpc fixes
Michael Tsirkin (1):
virtio/vhost updates
Miguel Ojeda (1):
compiler attribute updates
Mike Marshall (1):
orangefs updates
Mike Snitzer (1):
device mapper updates
Miklos Szeredi (2):
fuse updates
overlayfs updates
Nicolas Pitre (1):
cramfs fixes
Olof Johansson (1):
ARM SoC fixes
Palmer Dabbelt (3):
RISC-V updates
more RISC-V updates
RISC-V defconfig update
Paul Burton (2):
MIPS fixes
MIPS updates
Paul Moore (1):
SELinux updates
Petr Mladek (1):
printk updates
Radim KrÄmÃÅ (1):
KVM updates
Rafael Wysocki (4):
power management updates
ACPI updates
more power management updates
more ACPI updates
Richard Weinberger (2):
UML updates
UBIFS updates
Rob Herring (2):
Devicetree updates
Devicetree fixes
Russell King (1):
ARM updates
Sebastian Reichel (1):
power supply and reset updates
Shaohua Li (1):
md updates
Shuah Khan (1):
kselftest updates
Stephen Boyd (1):
clk updates
Steve French (2):
cifs updates
cifs fixes and updates
Steven Rostedt (2):
tracing fixes
tracing updates
Takashi Iwai (2):
sound updates
sound fixes
Ted Ts'o (1):
ext4 updates
Tejun Heo (1):
cgroup updates
Thierry Reding (1):
pwm updates
Thomas Gleixner (3):
timekeeping updates
irq updates
more timer updates
Tony Luck (1):
ia64 updates
Trond Myklebust (2):
NFS client updates
NFS client bugfixes
Ulf Hansson (1):
MMC updates
Vinod Koul (1):
dmaengine updates
Wim Van Sebroeck (1):
watchdog updates
Wolfram Sang (2):
i2c updates
i2c fixes
Zhang Rui (1):
thermal management updates