On Tue, Sep 19, 2017 at 01:37:19PM -0700, Christoph Hellwig wrote: > On Tue, Sep 19, 2017 at 09:17:28PM +0200, Florian Weimer wrote: > > 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. > > (f)pathconf is defined as: > > long fpathconf(int fd, int name); > long pathconf(const char *path, int name); > > so there really shouldn't be any issue. There might be some tricky bits will be if glibc feels it needs to override the values returned by the kernel (if it believes it may impose some limitations due to its implementation). Also, not all file systems will implement some or all pathconf parameters initially (or perhaps ever). So should the VFS be responsible for returning some intelligent defaults, or glibc? Also, will application programs want to know whether they are getting kernel values versus glibc's best guess (which may be depedent on the kernel version, modulo distributions / handset/tablet vendors who might decide to backport the syscall to their kernels)? It might be a good idea to come to a rough agreement (between the kernel and glibc devs) about how to handle some of these practical issues up front. Cheers, - Ted -- 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
