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

[Andreas Dilger]

On Jun 17, 2009  01:25 +0100, David Howells wrote:
> Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> wrote:
> > But if we add an ABI we end up stuck with it and this one is really
> > really rather ugly.
> 
> Somewhat less ugly than ioctl, for instance, but you're not entirely wrong.
> There is no good way of doing this.
> 
> > 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).

What about opening the mountpoint (which HAS to be available) and then
calling an ioctl() on that?  At least the mess would be contained within
AFS instead of requiring several new syscalls.

> Besides, I want a set of utilities that I can use in conjunction with both
> kAFS and OpenAFS without having to recompile.

That doesn't mean it isn't possible to have the same user-space utilities,
just that the pioctl() wrapper will need to multiplex its behaviour depending
on whether it is working with kAFS or OpenAFS.

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.

--
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/