> > Can you not put pioctl() into a C library linked with the openafs utilities > > that generates more sensible interface calls? I mean you have to produce > > the pioctl() syscall wrapper anyway so why not make "pioctl" a user space > > compat library? > > pioctl() is almost implementable with a combination of (l)setxattr, > (l)getxattr, set_key, keyctl_read, and if all else fails, open + ioctl or > open(O_NOFOLLOW) + ioctl, but not quite completely. There are things you can't > open, even with O_NOFOLLOW. And doing state-retaining setxattr/getxattr pairs > is even more nasty than pioctl (IIRC, that's something Christoph suggested a > while back). > > Besides, I want a set of utilities that I can use in conjunction with both kAFS > and OpenAFS without having to recompile. "I want" isn't a good policy for the introduction of ugly as sin long term interfaces into the kernel. Besides which you argument doesn't actually make sense anyway. If you have to put a pioctl() wrapper in a library then you can compile both sets of tools with your wrapper library and the library can do the relevant gunge to decide how to make the kernel calls and which ones to make. The pioctl() interface is crap, keep it in user space wrappers and put actual proper structured interfaces into the kernel. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
