I think you need to explain the rationale more thoroughly. If the only pathconf parameters that might vary by filesystem implementation are ones that libdiskfs has (or can easily have) other information about, then I think it's better not to add this new "flexibility". It's just an opportunity for filesystem writers to introduce bugs.
e.g., for _PC_2_SYMLINKS the answer is "true iff the filesystem either sets diskfs_shortcut_symlink or supports setting passive translators generally". I don't think there's a way for libdiskfs to answer the latter question right now. But it would be better to add a way to answer that question than to add a pathconf hook that serves no other purpose. For example, the interface contract for diskfs_set_translator could be changed to allow calling with all NULL arguments. That use would return 0 if diskfs_set_translator on this filesystem can ever succeed, and EOPNOTSUPP if not. In ext2fs and ufs this would check the global state (sblock->s_creator_os and compat_mode, respectively). In fatfs it already just returns failure always (but would need to avoid the assert on !diskfs_readonly when passed NULL arguments). In tmpfs, it would return success always. Etc. Thanks, Roland
