5 ms·

There's an assumption which this article makes which is not true; namely, that the only utilities which do (or should) use ioctl's are system programs like ipco

by tytso 7y ago

There's an assumption which this article makes which is not true; namely, that the only utilities which do (or should) use ioctl's are system programs like ipconfig which are shipped with the kernel. There are other programs, like for example Kerberos, who want to know what network addresses are used by the network, and requiring them to screen scrape ipconfig is not especially reasonable. So if you randomly change ioctls, then you randomly break other programs that might not be shipped with the kernel that need to use those ioctls. Maintaining proper backwards compatibility for userspace applications, and not labelling some set of interfaces as "can randomly change, and if you use them and you're aren't part of the privileged set of programs shipped with the kernel, well, it just sucks to be you", is not, in my opinion a professional way to run an OS.

kazinator 7y ago
(Is that you Ted?) I kind of said the same thing just now: https://news.ycombinator.com/item?id=22629837 https://news.ycombinator.com/item?id=22629837
loeg 7y ago
It seems like for many userspace applications, the appropriate backwards compatibility ABI would have been at the SO level. ELF shlibs make it easy to version interfaces without breaking old dynamically linked programs. Linux is sort of the odd duck in that it considers the entire syscall surface a stable ABI. It leads to a lot of neat results, but can obviously also cause pain when some older interfaces are not sufficient. That said — new ioctls could be added and new ifconfig could use those? Old ifconfig and user programs could continue using the old ABIs.
- spacenick88 7y ago
  I would argue that the stable syscall interfaces is one of the main drivers behind Linux success. Containers as we know them would be quite different if they needed to somehow merge the kernel version appropriate .so files into the fs. They would forever remain just sandboxes of the essentially the same distro as the host just like they are on Solaris/FreeBSD. Also something like WSL would be impossible
  - loeg 7y ago
    > I would argue that the stable syscall interfaces is one of the main drivers behind Linux success. Containers as we know them would be quite different if they needed to somehow merge the kernel version appropriate .so files into the fs. They would forever remain just sandboxes of the essentially the same distro as the host just like they are on Solaris/FreeBSD. I suspect the order of cause and effect is reversed. Linux is amazingly successful and as a result containers were shaped to fit the capabilities and needs of Linux. The reason Linux has a strong syscall ABI is because it doesn't have a userspace. Glibc is only loosely related to the kernel and cannot be the kernel's ABI compatibility layer, as they are wholly independent projects. Another way of looking at this is that the overhead and additional abstraction of containers is a workaround for the deficiencies of Linux jail/zone facilities (i.e., it doesn't have them; you have to carefully piece together a secure sandbox out of various cgroup and namespace components). > Also something like WSL would be impossible Some interesting things about that: 1. WSLv1 was a partial Linux syscall emulator, sure. 2. Microsoft gave up on that approach and WSLv2 is just an Ubuntu VM running in HyperV. So maybe it was impossible anyway — Linux just provides a ton of system calls and it will always be difficult to faithfully implement all of them. And as some side threads have noted, Linux likes to break ABI of sysfs files all the time. But those don't count, for some reason. 3. FreeBSD has a linux syscall emulation layer (that long predates WSL) using essentially the same premise as WSLv1. You're correct that this style of implementation (syscall ABI) only works due to Linux's syscall ABI choices. 4. However, something like WSL is not impossible against a shlib ABI. The canonical example here is WINE. WINE implements (much of) the Windows NT shared library (DLL) level stable ABI. The same could be done for other systems that provide ABI stability at the DLL level, such as MacOS or FreeBSD.
touisteur 7y ago
But, for finding interfaces and read about their state and settings, aren't /proc and /sys the best way to go, if there is no worry about toctou? I was answered yesterday on another topic that /proc is a linuxism, but is there anything missing there ?
- mixmastamyk 7y ago
  /proc is originally a Bell Labs and Plan9ism.
mixmastamyk 7y ago
A long, overlapping deprecation period is the typical way of handling this. Why is this avoided at the lower levels?
andyjpb 7y ago
Yes! He also mentions that NetBSD and OpenBSD have "kernel interface itself is highly stable anyways" but doesn't elaborate on how that's different from Linux's interface stability. The argument doesn't hang together. He can't claim that changes to userland tools aren't possible whilst at the same time claiming it's because the existing interfaces never change.

by tytso 7y ago

kazinator 7y ago

(Is that you Ted?) I kind of said the same thing just now: https://news.ycombinator.com/item?id=22629837 https://news.ycombinator.com/item?id=22629837

loeg 7y ago

It seems like for many userspace applications, the appropriate backwards compatibility ABI would have been at the SO level. ELF shlibs make it easy to version interfaces without breaking old dynamically linked programs. Linux is sort of the odd duck in that it considers the entire syscall surface a stable ABI. It leads to a lot of neat results, but can obviously also cause pain when some older interfaces are not sufficient. That said — new ioctls could be added and new ifconfig could use those? Old ifconfig and user programs could continue using the old ABIs.

spacenick88 7y ago
I would argue that the stable syscall interfaces is one of the main drivers behind Linux success. Containers as we know them would be quite different if they needed to somehow merge the kernel version appropriate .so files into the fs. They would forever remain just sandboxes of the essentially the same distro as the host just like they are on Solaris/FreeBSD. Also something like WSL would be impossible
- loeg 7y ago
  > I would argue that the stable syscall interfaces is one of the main drivers behind Linux success. Containers as we know them would be quite different if they needed to somehow merge the kernel version appropriate .so files into the fs. They would forever remain just sandboxes of the essentially the same distro as the host just like they are on Solaris/FreeBSD. I suspect the order of cause and effect is reversed. Linux is amazingly successful and as a result containers were shaped to fit the capabilities and needs of Linux. The reason Linux has a strong syscall ABI is because it doesn't have a userspace. Glibc is only loosely related to the kernel and cannot be the kernel's ABI compatibility layer, as they are wholly independent projects. Another way of looking at this is that the overhead and additional abstraction of containers is a workaround for the deficiencies of Linux jail/zone facilities (i.e., it doesn't have them; you have to carefully piece together a secure sandbox out of various cgroup and namespace components). > Also something like WSL would be impossible Some interesting things about that: 1. WSLv1 was a partial Linux syscall emulator, sure. 2. Microsoft gave up on that approach and WSLv2 is just an Ubuntu VM running in HyperV. So maybe it was impossible anyway — Linux just provides a ton of system calls and it will always be difficult to faithfully implement all of them. And as some side threads have noted, Linux likes to break ABI of sysfs files all the time. But those don't count, for some reason. 3. FreeBSD has a linux syscall emulation layer (that long predates WSL) using essentially the same premise as WSLv1. You're correct that this style of implementation (syscall ABI) only works due to Linux's syscall ABI choices. 4. However, something like WSL is not impossible against a shlib ABI. The canonical example here is WINE. WINE implements (much of) the Windows NT shared library (DLL) level stable ABI. The same could be done for other systems that provide ABI stability at the DLL level, such as MacOS or FreeBSD.

touisteur 7y ago

But, for finding interfaces and read about their state and settings, aren't /proc and /sys the best way to go, if there is no worry about toctou? I was answered yesterday on another topic that /proc is a linuxism, but is there anything missing there ?

mixmastamyk 7y ago
/proc is originally a Bell Labs and Plan9ism.

mixmastamyk 7y ago

A long, overlapping deprecation period is the typical way of handling this. Why is this avoided at the lower levels?

andyjpb 7y ago

Yes! He also mentions that NetBSD and OpenBSD have "kernel interface itself is highly stable anyways" but doesn't elaborate on how that's different from Linux's interface stability. The argument doesn't hang together. He can't claim that changes to userland tools aren't possible whilst at the same time claiming it's because the existing interfaces never change.