On Tue, Sep 19, 2017 at 10:55:20AM -0400, Theodore Ts'o wrote: > Maybe the right answer is we should define a new pathconfat(2) system > call which can be used as part of a C library's implementation of > pathconf() and fpathconf()? glibc probably won't use it for years, of > course. But we can at least provide the information via an interface > which we can control, and which is capable of returning correct > results? glibc is very fast at picking up new kernel interface these days as long as they aren't too controversial. Implementing a syscall that backs a function they implement should not be in the controversial category I think.
