Why not move the backward compatibility layer out of kernel into libc?

Posted Jan 8, 2015 12:24 UTC (Thu) by skissane (subscriber, #38675)
In reply to: Why not move the backward compatibility layer out of kernel into libc? by mebrown
Parent article: Haunted by ancient history

But surely libc could provide an ioctl function which doesn't directly call the ioctl system call, but does other things? i.e. check ioctl number, if it has certain values, don't call the ioctl system call, call some other function instead. Then that other function could then emulate old ioctls by calling netlink.

Why not move the backward compatibility layer out of kernel into libc?

Posted Jan 8, 2015 14:26 UTC (Thu) by rsidd (subscriber, #2582) [Link]

It would still break backward compatibility, which means binary compatibility. Modifying source is easy.

Why not move the backward compatibility layer out of kernel into libc?

Posted Jan 10, 2015 17:54 UTC (Sat) by nix (subscriber, #2304) [Link]

Sure -- but glibc is generally upgraded much *less* often than the kernel, not much more often, and a world in which you find your wireless interface is broken if you upgrade your kernel until you upgrade glibc too is not a remotely desirable one. Sure, glibc can include backward-compatibility code for old kernels, and does, but an old glibc is already released cannot contain such code. The only solution there is for the *kernel* to contain backwards-compatibility code in case it is used with an older glibc.

Since this is exactly the situation now, the only effect of your change would be to double the amount of compatibility code that would need to be retained nearly forever.