On Wed, Feb 19, 2020 at 7:08 AM David Howells <dhowells@xxxxxxxxxx> wrote:
>
>
> Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote:
>
> > The above nicely explains what the patch does.
> > However, unless I'm missing something, this fails to explain the "why"
> > (except for the vague "[...] is something that AFS needs ...".
>
> I'm not allowed to implement pioctl() for Linux, so I have to find some other
> 'structured' (to quote Linus) way to implement the extra functions for the
> in-kernel AFS client.
Honestly, the "create_mountpoint()" thing isn't any better. It's worse
and exposes an interface that makes no sense.
What are the insane pioctl semantics you want?
If you can't even open a file on the filesystem, you damn well
shouldn't be able to to "pioctl" on it.
And if you *can* open a file on the filesystem, why can't you just use
ioctl on it?
So no, the new system calls make no sense, and your explanation for
them is lacking too.
Give a very concrete example of what you want to do, and why AFS would
be so super-duper-magical, and why you can't just use ioctl on an
existing directory.
And no, "maybe the directories aren't readable" isn't an excuse, as
mentioned. Why the hell would you want to do pioctl on a non-readable
path in the first place?
Linus
