Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1273710

Re: [RFC] readlink()-related oddities

From Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups linux.kernel
Subject Re: [RFC] readlink()-related oddities
Date 2015-11-20 04:20 +0100
Message-ID <qwKoV-1E5-3@gated-at.bofh.it> (permalink)
References <qwGOm-7Dg-15@gated-at.bofh.it> <qwJsR-Wv-7@gated-at.bofh.it> <qwK5z-1aE-3@gated-at.bofh.it> <qwKff-1tW-3@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Thu, Nov 19, 2015 at 7:09 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> So there is *potential* for just making it generic, but that doesn't
> mean that it necessarily has to act that way.

.. it's not necessarily just readlink() either. I still think it might
be a perfectly fine idea to allow non-directories to act as
directories in some case (by exposing "readdir" and "lookup").

But readdir() really doesn't sound horrible either. how about unix
domain sockets (or named pipes) giving their link information when you
do readdir() on them?

Quite frankly, I think allowing those kinds of unified interfaces is
better than the current situation where you have to use a
"getpeername()" system call etc. If it's a filesystem object, why not
allow filesystem operations to work on it?

We expose some things in /proc as symlinks things that actually would
work better as non-symlinks, exactly *because* we want to expose not
just the end result of what they point to, but also a *description* of
what they point to. So we have those odd "pseudo-symlinks" in /proc
that don't actually really do a pathname walk on the symlink content
they expose, but still *look* like symlinks just because readdir() is
such a useful thing to have.

No wonder other users have wanted to use it.

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

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[RFC] readlink()-related oddities Al Viro <viro@ZenIV.linux.org.uk> - 2015-11-20 00:30 +0100
  Re: [RFC] readlink()-related oddities Linus Torvalds <torvalds@linux-foundation.org> - 2015-11-20 03:20 +0100
    Re: [RFC] readlink()-related oddities Al Viro <viro@ZenIV.linux.org.uk> - 2015-11-20 04:00 +0100
      Re: [RFC] readlink()-related oddities Linus Torvalds <torvalds@linux-foundation.org> - 2015-11-20 04:10 +0100
        Re: [RFC] readlink()-related oddities Linus Torvalds <torvalds@linux-foundation.org> - 2015-11-20 04:20 +0100
          Re: [RFC] readlink()-related oddities Al Viro <viro@ZenIV.linux.org.uk> - 2015-11-20 04:30 +0100
      Re: [RFC] readlink()-related oddities David Howells <dhowells@redhat.com> - 2015-11-20 11:10 +0100
  Re: [RFC] readlink()-related oddities David Howells <dhowells@redhat.com> - 2015-11-20 11:00 +0100
    Re: [RFC] readlink()-related oddities Al Viro <viro@ZenIV.linux.org.uk> - 2015-11-20 17:10 +0100
      Re: [RFC] readlink()-related oddities David Howells <dhowells@redhat.com> - 2015-11-20 17:30 +0100
    Re: [RFC] readlink()-related oddities Al Viro <viro@ZenIV.linux.org.uk> - 2015-11-20 23:40 +0100

csiph-web