[lkml]   [2001]   [May]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
    On Thursday 24 May 2001 22:59, Edgar Toernig wrote:
    > Daniel Phillips wrote:
    > > > > 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 kernel may know it, but the app? Or do you really want
    > > > to give different stat data on stat(2) and fstat(2)? These flags
    > > > are currently used by archive/backup prgs. It's a hint that
    > > > these files are not regular files and shouldn't be opened for
    > > > reading. Having a 'd' would mean that they would really try to
    > > > enter the directory and save it's contents. Don't know what
    > > > happens in this case to your "special" files ;-)
    > >
    > > I guess that's much like the question 'what happens in proc?'.
    > And that's already bad enough. Most of the "files" in proc should
    > be fifos! And using proc as an excuse to introduce another set of
    > magic dirs? No, thanks.

    Wait a second, I thought proc was here to stay. Wait another
    second, device nodes are already magic. Magic is magic, just
    choose your color ;-)

    This set of magic dirs is supposed to clean things up, not mess things
    up. We already saw how the side-effects-on-open problem in ls -l goes
    away. There's a much bigger problem I'd love to deal with: the 'no
    heirarchy can please everybody' problem. In database terms, aheirarchy
    is an insufficiently general model for real-world problems, in other
    words, they never worked. Tables work. That's where I'm trying to go
    with this, so please bear with me. This is not just a solution in
    search of a problem.

    > > Correct me if I'm wrong, but what we learn from the proc example
    > > is that tarring your whole source tree starting at / is not
    > > something you want to do.
    > IMHO it would be better to fix proc instead of adding more magic. At
    > the moment you have to exclude /proc. You want to add /dev.

    Well, actually no, ls -R, tar, zip, etc, work pretty well with the
    scheme I've described.

    > And
    > next? Exclude all $HOME/dev (in case process name spaces get added)?
    > Or make fifos magic too and add all of them to the exclude list? But
    > there's no central place for fifos. So lets add more magic :-(

    No, no, no, agreed and sometimes magic is good. It's not deep magic.
    The only new thing here is the interpretation of the O_DIRECTORY flag,
    or rather, the lack of it.

    > > What *won't* happen is, you won't get side effects from opening
    > > your serial ports (you'd have to open them without O_DIRECTORY
    > > to get that) so that seems like a little step forward.
    > As already said: depending on O_DIRECTORY breaks POSIX compliance
    > and that alone should kill this idea...

    Thanks, two good points:
    - libc5 will get confused when doing ls in /magicdev
    - POSIX specifically forbids this

    I'll put this away until I've specifically dug into both of them. OK,
    over and out, thanks for your commentary.

    /me peruses man pages

    Oops, oh wait, there's already another open point: your breakage
    examples both rely on opening ".". You're right, "." should always be
    a directory and I believe that's enforced by the VFS. So we don't have
    an example of breakage yet.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

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