everything is a directory - Plan9

This is a discussion on everything is a directory - Plan9 ; On 9/1/07, Uriel wrote: > With this way of thinking we will never catch up with lunix's 400 > syscalls (and counting, not to mention the ioctls)! We're partly there in spirit; what fraction of the 4e kernel's system calls ...

+ Reply to Thread
Page 4 of 4 FirstFirst ... 2 3 4
Results 61 to 73 of 73

Thread: everything is a directory

  1. Re: [9fans] Re: everything is a directory

    On 9/1/07, Uriel wrote:
    > With this way of thinking we will never catch up with lunix's 400
    > syscalls (and counting, not to mention the ioctls)!


    We're partly there in spirit; what fraction of the 4e kernel's system
    calls are there for backwards compatibility?

    Back on topic, I wasn't proposing a readdir() syscall but pointing out
    that Douglas's suggestion would not in fact be painless or transparent
    under Plan 9.

    --Joel

  2. Re: [9fans] Re: everything is a directory

    > We're partly there in spirit; what fraction of the 4e kernel's system
    > calls are there for backwards compatibility?


    i don't know if that's a rhetorical question or not. it's not hard to answer.

    /sys/src/libc/9syscall/sys.h lists 51 system calls. ten have underscores.
    OSEEK is also obsolete. that would make 22%.

    - erik


  3. Re: [9fans] Re: everything is a directory

    > /sys/src/libc/9syscall/sys.h lists 51 system calls.
    > ten have underscores. OSEEK is also obsolete.
    > that would make 22%.


    If you count DEATH and PASSFD in sysproc.c and
    sysfile.c, respectively, then it's 25%. They
    are the missing syscall numbers 48 and 49.

    --
    "Christ, what an imagination I've got." - Shalmaneser

  4. Re: [9fans] Re: everything is a directory

    On 9/2/07, Joel C. Salomon wrote:
    > On 9/1/07, Uriel wrote:
    > > With this way of thinking we will never catch up with lunix's 400
    > > syscalls (and counting, not to mention the ioctls)!

    >
    > We're partly there in spirit; what fraction of the 4e kernel's system
    > calls are there for backwards compatibility?
    >
    > Back on topic, I wasn't proposing a readdir() syscall but pointing out
    > that Douglas's suggestion would not in fact be painless or transparent
    > under Plan 9.


    Indeed, and I would say that is a feature, not a bug. (Adding an extra
    syscall to read dirs would be a bug). But maybe my sarcasm got lost
    along the way.

    And actually, I think one could have something similar to Douglas
    suggestion in Plan 9 without changing the kernel or the vfs, or even
    the file servers, just have a stackable file server which for every
    original file /foo.txt allows you to access a /foo.txt@extendedjunk/
    dir where all the extended attributes or whatever can live, that would
    even keep backwards compatibility with all existing tools (tools that
    don't know about @extendedjunk/ dirs would not even see them unless
    they explicitly walk to them, so you could use cd
    /foo.txt@extenedjunk/, followed of ls and cat to inspect the
    attributes, but if you do cat /* or ls / you would get a sensible
    output.

    Anyway, I still think it would be a waste of time, but like unix in
    its day, plan9 makes adding new 'features' rather easy, whatever they
    are worthy or another symlink-hell awaiting to happen is another
    question.

    Best wishes

    uriel

    P.S.: The Plan 9 industry is not creating enough jobs, we need more
    syscalls! And dynamic linking!

  5. Re: [9fans] Re: everything is a directory

    On 9/2/07, Uriel wrote:
    > And actually, I think one could have something similar to Douglas
    > suggestion in Plan 9 without changing the kernel or the vfs, or even
    > the file servers, just have a stackable file server which for every
    > original file /foo.txt allows you to access a /foo.txt@extendedjunk/
    > dir where all the extended attributes or whatever can live, that would
    > even keep backwards compatibility with all existing tools (tools that
    > don't know about @extendedjunk/ dirs would not even see them unless
    > they explicitly walk to them, so you could use cd
    > /foo.txt@extenedjunk/, followed of ls and cat to inspect the
    > attributes, but if you do cat /* or ls / you would get a sensible
    > output.


    Or how about this: Just as you don't need read permissions on a
    directory to walk it -- so long as you know the name of the file you
    want -- how about 9p allowing walks to ordinary files. /foo.txt will
    exist, and reads work as usual, but /foo.txt/metadata.xml (of course
    it's all buzzword-compliant XML!) can be walked to and manipulated.
    Disgusting, eh?

    --Joel

  6. Re: [9fans] Re: everything is a directory

    Disgusting indeed, but it might even work with no changes to 9P; it
    might confuse some clients, but doesn't sound easily doable given some
    basic naming conventions (of course, then you lose the possibility to
    cd into that dir and run ls there, which is the main reason I thought
    an extension to the file name would make more sense)

    uriel

    On 9/2/07, Joel C. Salomon wrote:
    > On 9/2/07, Uriel wrote:
    > > And actually, I think one could have something similar to Douglas
    > > suggestion in Plan 9 without changing the kernel or the vfs, or even
    > > the file servers, just have a stackable file server which for every
    > > original file /foo.txt allows you to access a /foo.txt@extendedjunk/
    > > dir where all the extended attributes or whatever can live, that would
    > > even keep backwards compatibility with all existing tools (tools that
    > > don't know about @extendedjunk/ dirs would not even see them unless
    > > they explicitly walk to them, so you could use cd
    > > /foo.txt@extenedjunk/, followed of ls and cat to inspect the
    > > attributes, but if you do cat /* or ls / you would get a sensible
    > > output.

    >
    > Or how about this: Just as you don't need read permissions on a
    > directory to walk it -- so long as you know the name of the file you
    > want -- how about 9p allowing walks to ordinary files. /foo.txt will
    > exist, and reads work as usual, but /foo.txt/metadata.xml (of course
    > it's all buzzword-compliant XML!) can be walked to and manipulated.
    > Disgusting, eh?
    >
    > --Joel
    >


  7. Re: [9fans] Re: everything is a directory

    "Joel C. Salomon" wrote ...
    > Back on topic, I wasn't proposing a readdir() syscall but pointing out
    > that Douglas's suggestion would not in fact be painless or transparent
    > under Plan 9.


    Since I was unable to get Plan9 installed successfully when I set up
    my home systems, and can't use it at work, I don't have direct
    experience with its implementation. I had been thinking that the
    Twalk part of 9P was connected with getting directory entries.
    However, if dirread() is used instead, then the implementation of
    dirread() would of course have to change (turn into a syscall,
    with stuff added to 9P and the various file servers, alas). That
    would indeed require a lot of work. Unix already made the
    change a couple of decades ago.

  8. Re: [9fans] Re: everything is a directory

    > Unix already made the
    > change a couple of decades ago.


    plan 9's definition of read on a directory, and the definition of the data
    thereby returned, is different from Unix's and there was no
    need to make a change. for instance, the data returned is unrelated
    to any underlying storage structure, which is just as well, because it's
    usually just some data structures in a program.

    actually, since Unix's data from reading a directory was essentially a sequence of (ino, name) tuples,
    that independence might have been true of Unix as well, but previously-used slots
    were revealed, and the names were fixed length, because it really was just the data read
    from the disc representation.


  9. Re: [9fans] Re: everything is a directory

    On 9/3/07, Uriel wrote:
    > Disgusting indeed, but it might even work with no changes to 9P; it
    > might confuse some clients, but doesn't sound easily doable given some
    > basic naming conventions (of course, then you lose the possibility to
    > cd into that dir and run ls there, which is the main reason I thought
    > an extension to the file name would make more sense)


    You don't want to run ls, remember. The point of this exercise is to
    conceptually add some form of metadata to files. All that's needed
    (if that!) is a set of attribute=value pairs, which can all be kept in
    a single 'file' with a known name and predetermined format. (Or a
    database with multiple file-like 'views', so meta.txt, meta.csv, and
    meta.xml are all available. Ick.)

    --Joel

  10. Re: [9fans] Re: everything is a directory

    Well, I expected people who wants extended attributes would want
    resource forks (double yuck) and who knows what else.

    Actually I think something like this was russ' suggestion at IWP9 to
    handle things like locking, symlinks and other PoSix junk.

    All that would be needed is a well defined convention, and then
    clients who cared about such extra 'features' could use them without
    changing 9p, existing servers or clients (which don't care about this
    'features').

    uriel

    On 9/3/07, Joel C. Salomon wrote:
    > On 9/3/07, Uriel wrote:
    > > Disgusting indeed, but it might even work with no changes to 9P; it
    > > might confuse some clients, but doesn't sound easily doable given some
    > > basic naming conventions (of course, then you lose the possibility to
    > > cd into that dir and run ls there, which is the main reason I thought
    > > an extension to the file name would make more sense)

    >
    > You don't want to run ls, remember. The point of this exercise is to
    > conceptually add some form of metadata to files. All that's needed
    > (if that!) is a set of attribute=value pairs, which can all be kept in
    > a single 'file' with a known name and predetermined format. (Or a
    > database with multiple file-like 'views', so meta.txt, meta.csv, and
    > meta.xml are all available. Ick.)
    >
    > --Joel
    >


  11. Re: [9fans] Re: everything is a directory

    On Aug 24, 2007, at 3:55 AM, David Leimbach wrote:

    >
    >
    > On 8/24/07, jsnx wrote:
    > On Aug 23, 3:35 am, st...@quintile.net (Steve Simon) wrote:
    > > I'am not trolling, I just don't see their efficacy in plan9.

    >
    > I don't see how to architect the system I discussed without
    > attributes.
    >
    > I can...
    >
    > Build yourself a file server that provides the environment you want
    > with attributes... don't inject it into the core system. Store it
    > for real in fossil files with a certain format.
    >
    > Done?
    >
    > Plan 9's ability to have synthetic filesystems seems to do away
    > with the need to change the way the core filesystems work.


    Speaking of which -- is there an easy way of implementing
    filtering filesystems? Something that would give
    a filter-server N existing [sub]trees and a set of instructions on
    how to reshuffle their content and represent
    it as a mountable output.

    Thanks,
    Roman.


  12. Re: [9fans] Re: everything is a directory

    On Aug 29, 2007, at 2:06 AM, jsnx wrote:

    > On Aug 24, 3:55 am, leim...@gmail.com (David Leimbach) wrote:
    >> On 8/24/07, jsnx wrote:
    >>> On Aug 23, 3:35 am, st...@quintile.net (Steve Simon) wrote:
    >>>> I'am not trolling, I just don't see their efficacy in plan9.
    >>> I don't see how to architect the system I discussed without
    >>> attributes.

    >> Build yourself a file server that provides the environment you
    >> want with
    >> attributes... don't inject it into the core system. Store it for
    >> real in
    >> fossil files with a certain format.
    >>
    >> Done?

    >
    > If I want to have a system with the features of two distinct
    > filesystems, what then? Attributes allow for composition, whereas the
    > FS oriented approach appears not to.


    I apologize for coming into the discussion a bit late. But I
    always wanted
    to share the following observation: metadata seems to be very
    confusing to
    an average joe. And when I say metadata I mean all
    metadata, not just resource forks and attributes. Time and again I've
    seen PC users name their digital picture (or at least directories with
    the digital pictures) _. Why? Well, because
    even though date and time are part of the metadata in pretty much
    every filesystem these days it is extremely difficult to make sure that
    all the tools handle them and preserve them just the way you want it
    to be
    (think about the time picture was taken vs. the time the file was
    created vs. the time it was last updated or even accessed).

    On top of the constant paranoia (Quiz-1: what's the option for cp to
    preserve the timestamp?) the metadata approach makes it very
    difficult to manipulate collections of files. Quiz-2: what's the
    moral equivalent
    of doing:

    $ cp 09_*_2007*.jpg ~/USA_tour

    if I didn't have date as part of the name?

    These usability issues with even the most established bits of
    file metadata such as date, time, owner, etc. show up often enough
    to make one think of if not abolishing metadata all together, at least
    not proliferating it any further.

    >
    > I would have to write (or obtain) a TeX fs, a SVN fs and then a TeX-
    > SVN fs if I wanted to have those feature sets independently, if I am
    > understanding you correctly.


    The problem you seem to be alluding to is genuine and I'll try to
    paraphrase it in order to see whether we're talking about the same
    thing. Suppose you have a collection of leaf-node objects that
    you can group together in a number of different ways. Suppose
    also that these groupings are mostly orthogonal to each other.
    Now, if you express objects as files -- what is the most natural
    way of expressing various groupings? To make it even more clear
    here's a practical example: in my build system I have to produce
    binaries for SPARC and x86 running under Solaris and Linux
    and each of those binaries either built for debugging or with
    maximum optimization. My objects are, obviously, files
    but how am I supposed to structure the groupings? It looks like
    three levels of subdirectories should do the trick giving me
    names like:
    sparc/linux/opt/binary
    Now, of course, even if we put aside questions like why not
    linux/sparc/opt/binary, we still have to figure out how to handle
    the case where the very same physical binary file happens to
    be a fat binary that can run on both SPARC and x86 Solaris
    OSes. Where should it go? Should we symlink to it from
    "the other" place? Questions like these seem to call for tagging and
    filter filesystems (see my previous question in this very thread).
    The scariest part is that they also come dangerously close to the
    oldest argument in the OS design history: filesystem abstraction
    vs. database abstraction for managing persistent data.

    Your hypothetical problem seems to fit exactly the same profile: your
    leaf-node objects are lines (or perhaps even sets of TeX lexems)
    and the grouping can either be determined based on which SCM
    delta a particular object belongs to or where it fits in a tree-like
    TeX document structure.

    The problem is genuine, and I don't know the right solution for
    it, but somehow I don't think the metadata would help here. It seems
    to me that you could be confusing a building block for a proper
    solution (e.g. tagging) with the solution itself. After all, if I can
    convince you that extended attributes ARE just a building block
    it shouldn't matter how they are implemented as long as the end result
    works properly.

    And as for implementation -- David's proposal seems to fit the bill
    perfectly.

    Thanks,
    Roman.


  13. Re: [9fans] Re: everything is a directory

    > Or how about this: Just as you don't need read permissions on a
    > directory to walk it -- so long as you know the name of the file you
    > want -- how about 9p allowing walks to ordinary files.


    you could do this (macos x does something very similar), but it would
    still have exactly the same problems that most of these schemes have;
    i.e. the metadata will be lost unless all tools in the path from source
    to destination are aware of its existence.

+ Reply to Thread
Page 4 of 4 FirstFirst ... 2 3 4