LWN: Comments on "The first half of the 5.2 merge window"

The first half of the 5.2 merge window

Sesse — Mon, 13 May 2019 08:42:49 +0000

They're removing support for ATA that is not through libata. Almost all legacy IDE drivers should have libata support these days, so indeed, the practical upshot is hda vs. sda.

CLONE_PIDFD

cyphar — Mon, 13 May 2019 06:01:18 +0000

From my understanding a clone2 is being worked on as we speak. But it should be noted that there are plenty of examples of "new syscalls with clear semantics" that are still painful (openat is a good example -- it copied the [broken] behaviour of open(2) ignoring any unknown flags).

CLONE_PIDFD

Cyberax — Sun, 12 May 2019 16:53:08 +0000

Ugh. This kind of API makes me mad. Why not just add a new syscall with clear semantics?!?

CLONE_PIDFD

brodo — Sun, 12 May 2019 16:38:12 +0000

Actually, the clone() system call will not return a file descriptor as its return value even if the CLONE_PIDFD flag is present; the return value is always the PID. Instead, if the CLONE_PIDFD is present, a file descriptor will be passed as clone's parent_tidptr argument. See samples/pidfd/pidfd-metadata.c for an example of how this works.

The first half of the 5.2 merge window

hrw — Sun, 12 May 2019 12:48:22 +0000

As usual I updated my syscall table to make it easier to follow which system calls are available on which architectures.

New filesystem ones are x86 only now but I hope that other archs will follow in 5.2 cycle.

https://fedora.juszkiewicz.com.pl/syscalls.html

The first half of the 5.2 merge window

grawity — Sat, 11 May 2019 10:03:49 +0000

"Note also that the support for legacy IDE devices has been deprecated, with an eye toward removal in 2021. If there is anybody out there still using IDE devices that have not been converted over to libata support"

Ahh, so 'legacy' in the sense of "still shows up as /dev/hda and not /dev/sda"? I was already afraid they were going to deprecate support for IDE in general.

The first half of the 5.2 merge window

RandyBolton — Sat, 11 May 2019 00:44:39 +0000

I believe 130k was meant instead of 4096, from the 'bpf: improve verifier scalability' patch description from Alexei Starovoitov:
"Faster and bounded verification time allows to increase insn_processed limit to 1 million from 130k."