On 09/19/2017 05:55 PM, Christoph Hellwig wrote:
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.
We have a significant backlog, but I don't expect opposition to patches
implementing syscall wrappers which are just slightly generic (and
pathconfat should really be fine).
Technically, pathconfat might be tricky to maintain if it's expected to
be a variadic dispatcher function, and the accompanying UAPI header
isn't very clean.
Thanks,
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
