[lkml]   [2009]   [Jun]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 00/17] [RFC] AFS: Implement OpenAFS pioctls(version)s

    On Wed, 17 Jun 2009, David Howells wrote:

    > Linus Torvalds <> wrote:
    > > What _I_ mean is that THIS IS IMPOSSIBLE TO DO FROM USER SPACE!
    > >
    > > Try it. Not doable. User space simply doesn't know enough, and has
    > > fundamental races with mount/umount.
    > Ummm... I'm not sure I completely agree. If you've managed to open, say,
    > "/afs", where's the race with mount/umount?

    Well, if you mean that you're going to have a new system call that then
    passes in both the 'fd' from that /afs open, _and_ the pathname you want
    to work on, then sure.

    But if you do that new system call, then what's the point again? You're
    back to pinfo() anyway.

    > > I just don't think "pioctl()" is a good one.
    > Out of interest, why not? Is it just because it's another multipexor? Or is
    > it because it's been abused to have pathless commands?

    No. It's because it's another _typeless_ multiplexor.

    Look at ioctl. It's a F*CKING DISASTER. Look at all the compat crap, and
    at the ioctl numbers that mean different things for different file types,
    and all the random sizing crap. You fixed the random sizing crap (at least
    it has well-defined "input" and "output" areas), and that's an
    improvement, but it's still just random numbers with no semantics.

    Now, you can take two approaches:

    - learn from your mistake, and not do another f*cking disaster that just
    takes a pathname instead of a fd. Do something else, that actually has
    semantics and has a well-defined input and output buffer.

    - do the same stupid thing over again, and never learn.

    And quite frankly, I know which of those choices I'd call "intelligent",
    and which of them I'd call "you're a f*cking moron for doing it".

    And guess which one "pioctl()" is. Just take a wild stab at it.

    > > You'd be better off with some modification of open and then use ioctl.
    > So you'd say use:
    > fd = open("/the/target/file", O_SUPPRESS | (nofollow?O_NOFOLLOW:0));
    > ioctl(fd, cmd, &args);
    > close(fd);

    Yes, I think that would be better. It's not perfect, because I think ioctl
    is still a f*cking broken mess (and with the sizing issue, it's arguably
    _worse_ then your pioctl), but at least we're not adding _another_ broken

    So I don't think the above is great either.

    What I'd really prefer is something that actually has semantics. Not just
    "here's input, here's output, do something random to it".

    > Do you also disagree with OpenAFS's idea of creating a proc file to open so
    > that you can do ioctls on that to emulate pioctl()? That would serve also.

    Oh yes, I think that's a piece of crap too.


     \ /
      Last update: 2009-10-18 23:28    [W:0.024 / U:36.852 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site