Linux 5.9 Set To Bring "Close_Range" System Call - Coordinated With FreeBSD Developers

[phoronix]

Phoronix: Linux 5.9 Set To Bring "Close_Range" System Call - Coordinated With FreeBSD Developers

The close_range() system call is intended to allow efficiently closing a range of file descriptors (or all file descriptors) of the calling task. This system call was devised in cooperation with FreeBSD developers...

http://www.phoronix.com/scan.php?page=news_item&px=Linux-5.9-Close-Range

[Volta]

The article isn't too clear about origin:

This is coordinated with the FreeBSD folks which have copied our version of
this syscall and in the meantime have already merged it in April 2019:

https://reviews.freebsd.org/D21627

https://svnweb.freebsd.org/base?view...evision=359836

[starshipeleven]

inb4 people claiming that parsing ascii stuff from /proc on a loop is better than a dedicated system call, and that this is bloating the kernel.

[kpedersen]

inb4 people claiming that parsing ascii stuff from /proc on a loop is better than a dedicated system call, and that this is bloating the kernel.

I don't think anyone claims that munging text files is better than a system call.

Arguably I would go one step further and state that /proc is "never" a good idea and shouldn't even exist

[GrayShade]

Bleh. An older version of dpkg had a loop like

for (int i = 0; i < sysconf(_SC_OPEN_MAX); i++) {
    close(i);
}

which ran before each exec() to avoid leaking files to child processes. They were using O_CLOEXEC, but thought it would be a good idea to do this just in case they missed one. And yes, sysconf() got called in the loop there.

I had that version of dpkg on Raspbian and it was horrendously slow. I'd rather have a way to say "mark each file I'm going to open from now on as O_CLOEXEC" (of course, that may or may not play well with other people's code) or some new posix_spawn() flag instead of this mess of closing random fds just in case.

[starshipeleven]

I don't think anyone claims that munging text files is better than a system call.

Well, someone did in the thread about the kernel call about mounted status https://www.phoronix.com/forums/foru...e-linux-kernel

Arguably I would go one step further and state that /proc is "never" a good idea and shouldn't even exist

Proc and Sys and whatever exist for shell scripts so admins can cobble together quick hacks to save the day, or for simple and basic embedded device use, and they are fine for that.

If you are using them with an actual program in an actual programming language you are bad and should feel bad.

[xnor]

If you are using them with an actual program in an actual programming language you are bad and should feel bad.

A lot of tools _have_ to use procfs and sysfs because there are no native APIs available...

But that is the unix way, not providing something that other OSs have provided for over 2-3 decades because it's based on ideas from over 4 decades ago.

[starshipeleven]

A lot of tools _have_ to use procfs and sysfs because there are no native APIs available...

Because noone is vehemently demanding for it and/or contributing it. Linux is adding stuff all the time, there is no religious cult that steals your kittens.

But that is the unix way, not providing something that other OSs have provided for over 2-3 decades because it's based on ideas from over 4 decades ago.

It's more like the opensource way, unless someone contributes something it probably won't be done by the current maintainers out of thin air and for free.

[Zan Lynx]

I don't think anyone claims that munging text files is better than a system call.

Arguably I would go one step further and state that /proc is "never" a good idea and shouldn't even exist

Text isn't that much slower than binary and it is a heck of a lot easier to keep compatibility and to use it from scripts.

Have you ever had to write netlink code? Without an existing library? I have. Because we wanted a library written in native Go code. It was a pretty horrific experience. The connection tracking devs should probably be given a good talking to about writing documentation instead of saying "Use the library." Which is also lacking in documentation.

[pal666]

not sure about freebsd, but linux certainly has O_CLOEXEC and you should use it instead of hacks which will break things which pass descriptors intentonally