C library system-call wrappers, or the lack thereof

Re:C library system-call wrappers, or the lack thereof by cesarb on Wednesday November 14, 2018 @01:04PM (#18452071)

> At the same time, Linux is a large, complex project with backward compatibility which does significantly less noodling around with the extant interface.

Take a look at the system call table:

    #define __NR_oldstat 18
    #define __NR_oldfstat 28
    #define __NR_oldolduname 59
    #define __NR_oldlstat 84
    #define __NR_olduname 109
    [...]
    #define __NR_dup3 330
    #define __NR_pipe2 331
    #define __NR_preadv2 378
    #define __NR_pwritev2 379

(And that's before the impending Y2038 changes to the API.)

The main difference is that, instead of defining a new symbol, a new system call number is defined. The effect is similar: a program using the new "stat" system call (106) won't work on an older kernel which doesn't have it, while on the opposite direction it still works (new kernels still understand the old system call).

One thing the kernel developers do nowadays to reduce the API churn is to add a flags argument to every new system call (for instance, the "dup3" above is the same as "dup2", but with a flags argument). Even then, if you try to use a flag which the current kernel doesn't know, it won't work (the kernel developers learned the hard way that you can't ignore unknown flags, since programs will pass them and then break on newer kernels).

And that's without considering the "escape hatches" of ioctl() and fcntl(), or the virtual filesystems like /proc and /sys, which are also part of the Linux kernel API. So yes, the Linux kernel does see regular interface changes.

[ Parent | on HN ]

Re:C library system-call wrappers, or the lack thereof by jancsika on Wednesday November 14, 2018 @06:37PM (#18455337)

Still trying to get my bearings, so bear with me...

Here are two different types of backward compatibility:

1. will old binary work with the new version?

2. will old code build and run correctly with the new version?

So when I talk about extant interface changes, I'm speculating that old code that leverages the public Linux interface is more likely to work and work correctly vs. old code that leverages the public glibc interface.

For example: suppose foodev built a Linux driver for a very popular piece of hardware in 2003, abandoned it, and in 2018 there are problems getting it to run correctly. Are those problems more likely due to Linux public interface churn or glibc public interface churn?

[ Parent | on HN ]

Re:C library system-call wrappers, or the lack thereof by cesarb on Wednesday November 14, 2018 @10:03PM (#18456545)

For a driver, there would be problems getting it to run correctly in 2004 already, since the internal Linux kernel API used by drivers is not stable and changes very rapidly. Unless the driver has been upstreamed, because developers updating the kernel internal APIs also update all the in-tree drivers at the same time.

About leveraging one interface or the other: when you use the glibc interface, you are also using the Linux interface behind it, so a change in either can affect your program. On the other hand, if you are using the Linux interface directly instead of going through the C library, chances are you are doing something unusual, which increases the risk of it breaking by accident. And there are some things which exist only on the glibc interface, like nameserver lookups (getaddrinfo), user database lookups (getpwnam/getpwuid), and many more.

[ Parent | on HN ]

Re:C library system-call wrappers, or the lack thereof by Annatar on Thursday November 15, 2018 @02:41AM (#18457573)

"For a driver, there would be problems getting it to run correctly in 2004 already,"

This is unthinkable on Solaris / illumos kernels because of DDI / DDK interfaces: I can take a driver from 1993 for Solaris 2.5.1 and modload(1M) it into the latest nightly illumos build and I'm guaranteed that it will work.

[ Parent | on HN ]