Re: [PATCH 00/17] [RFC] AFS: Implement OpenAFS pioctls(version)s

[Alan Cox]

> > 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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/