On Sun, Nov 11, 2018 at 11:53:54AM +0100, Michael Kerrisk (man-pages) wrote: > I'm not sure I'd view the glibc position quite so harshly (although > it is disappointing to me that bug 6399 remains open). I think they > are simply short of people to work on this task. I think so as well and really have great respect for this limitation, which differs from the technical arguments on the bugzilla trying to find every single good reason why using this syscall was wrong. (...) > A converse question that one could ask is: why did a culture > evolve whereby kernel developers don't take responsibility for > working with the major libc to ensure that wrappers are added as > part of the job of adding each new system call? Yes, I know, there > are some historical reasons (and even today, IMO, they do > themselves no favors by requiring a CLA), but glibc really is > a different place today, compared to where it was a few years > ago. I think the issue is a bit more complex : - linux doesn't support a single libc - glibc doesn't support a single OS In practice we all know (believe?) that both statements above are true but in practice 99% of the time there's a 1:1 relation between these two components. What we'd really need would be to have the libc interface as part of the operating system itself. I'm perfectly fine with glibc providing all the "high-level" stuff like strcpy(), FILE* operations etc, and all this probably is mostly system-independent. But the system interface could possibly be handled easier in the system itself, which would also provide a smoother adoption of new syscalls and API updates. It would also limit the hassle required to provide new syscalls, as if you start to have to contribute to two projects at once for a single syscall, it becomes really painful. But I don't know what changes that would require and it could really turn out that in the end I'm totally wrong about the expected benefits. Cheers, Willy
