lkml.org 
[lkml]   [2001]   [May]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
    Date
    On Wednesday 23 May 2001 06:19, Edgar Toernig wrote:
    > Daniel Phillips wrote:
    > > On Tuesday 22 May 2001 17:24, Oliver Xymoron wrote:
    > > > On Mon, 21 May 2001, Daniel Phillips wrote:
    > > > > On Monday 21 May 2001 19:16, Oliver Xymoron wrote:
    > > > > > What I'd like to see:
    > > > > >
    > > > > > - An interface for registering an array of related devices
    > > > > > (almost always two: raw and ctl) and their legacy device
    > > > > > numbers with a single userspace callout that does whatever
    > > > > > /dev/ creation needs to be done. Thus, naming and permissions
    > > > > > live in user space. No "device node is also a directory"
    > > > > > weirdness...
    > > > >
    > > > > Could you be specific about what is weird about it?
    > > >
    > > > *boggle*
    > > >
    > > >[general sense of unease]
    >
    > I fully agree with Oliver. It's an abomination.

    We are, or at least, I am, investigating this question purely on
    technical grounds - name calling is a noop. I'd be happy to find a
    real reason why this is a bad idea but so far none has been
    presented.

    Don't get me wrong, the fact that people I respect have reservations
    about the idea does mean something to me, but this still needs to be
    investigated properly. Now on to the technical content...

    > > > I don't think it's likely to be even workable. Just consider the
    > > > directory entry for a moment - is it going to be marked d or
    > > > [cb]?
    > >
    > > It's going to be marked 'd', it's a directory, not a file.
    >
    > Aha. So you lose the S_ISCHR/BLK attribute.

    Readdir fills in a directory type, so ls sees it as a directory and does
    the right thing. On the other hand, we know we're on a device
    filesystem so we will next open the name as a regular file, and find
    ISCHR or ISBLK: good.

    The rule for this filesystem is: if you open with O_DIRECTORY then
    directory operations are permitted, nothing else. If you open without
    O_DIRECTORY then directory operations are forbidden (as
    usual) and normal device semantics apply.

    If there is weirdness anywhere, it's right here with this rule. The
    question is: what if anything breaks?

    > > > If it doesn't have the directory bit set, Midnight commander
    > > > won't let me look at it, and I wouldn't blame cd or ls for
    > > > complaining. If it does have the 'd' bit set, I wouldn't blame
    > > > cp, tar, find, or a million other programs if they did the wrong
    > > > thing. They've had 30 years to expect that files aren't
    > > > directories. They're going to act weird.
    > >
    > > No problem, it's a directory.
    >
    > Directories are not allowed to be read from/written to. The VFS may
    > support it, but it's not (current) UNIX.

    Here, we obey this rule: if you open it with O_DIRECTORY then you
    can't read from or write to it.

    > > > Linus has been kicking this idea around for a couple years now
    > > > and it's still a cute solution looking for a problem. It just
    > > > doesn't belong in UNIX.
    > >
    > > Hmm, ok, do we still have any *technical* reasons?
    >
    > So with your definition, I have a fs-object that is marked as a
    > directory but opening it opens a device. Pretty nice..

    No, you have to open it without O_DIRECTORY to get your device
    fd handle.

    > How I'm supposed to list it's contents? open+readdir?

    Nothing breaks here, ls works as it always did.

    This is what ls does:

    open("foobar", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3
    fstat(3, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
    fcntl64(0x3, 0x2, 0x1, 0x2) = -1 ENOSYS (Function not implemented)
    fcntl(3, F_SETFD, FD_CLOEXEC) = 0
    brk(0x805b000) = 0x805b000
    getdents64(0x3, 0x8058270, 0x1000, 0x26) = -1 ENOSYS (Function not implemented)
    getdents(3, /* 2 entries */, 2980) = 28
    getdents(3, /* 0 entries */, 2980) = 0
    close(3) = 0

    Note that ls doesn't do anything as inconvenient as opening
    foobar as a normal file first, expecting that operation to fail.

    > But the open has nasty side effects.
    > So you have a directory that you are not allowed
    > to list (because of the possible side effects) but is allowed to be
    > read from/written to maybe even issue ioctls to?.

    No, you would get side effects only if you open as a regular file.
    I'd agree that that sucks, but that's not what we're trying to fix
    just now.

    > And you call that sane???

    I would hope it seems saner now, after the clarification.
    Please, if you know something that actually breaks, tell me.

    --
    Daniel
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 12:53    [W:0.027 / U:30.760 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site