[9fans] Porting to plan9 / PF_UNIX - Plan9

This is a discussion on [9fans] Porting to plan9 / PF_UNIX - Plan9 ; I'm the developer of a Unix program that may be useful in plan9, and as an exercise, I'd like it to build in plan9 native. Now, I've written it assuming POSIX (int signals, PF_UNIX available, BSD sockets API, ...). I ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: [9fans] Porting to plan9 / PF_UNIX

  1. [9fans] Porting to plan9 / PF_UNIX

    I'm the developer of a Unix program that may be useful in plan9, and
    as an exercise, I'd like it to build in plan9 native.

    Now, I've written it assuming POSIX (int signals, PF_UNIX available,
    BSD sockets API, ...). I know more or less some details on plan9 (per
    process namespaces, network not in a library to link with, notes,
    ....), but I barely know the 'common' use of the environment.

    My concern is that I need some local processes to communicate to a
    local server. Now I use a SOCK_STREAM PF_UNIX in a path in /tmp, where
    I suppose I can write. I think it's something I can suppose in a POSIX
    system, but not in plan9.
    How would you connect local processes (which can be launched at any
    time) with a central server in plan9? Making that central server serve
    a filesystem, where the clients write/read?
    If I knew what's the path I should follow, I could think more easily
    on a proper API for POSIX and Plan9 for my program.

    I may not have not worked in plan9 enough to deserve your attention,
    but I hope a quick answer (even in the form of "man ___") will not
    take much time.

    btw, the program I'd like to be able to run in plan9 is
    http://vicerveza.homeunix.net/~viric/soft/ts/ . I wrote it because I
    couldn't find anything similar to fit my needs, and maybe in plan9 you
    already have something quick-and-useful for that purpose, and 'ts'
    would not make any sense in p9 now. That's also something I'd be glad
    to know.

    Thanks in advance,
    Lluís.

  2. Re: [9fans] Porting to plan9 / PF_UNIX

    Lluís Batlle wrote:
    > I'm the developer of a Unix program that may be useful in plan9, and
    > as an exercise, I'd like it to build in plan9 native.
    >
    > Now, I've written it assuming POSIX (int signals, PF_UNIX available,
    > BSD sockets API, ...). I know more or less some details on plan9 (per
    > process namespaces, network not in a library to link with, notes,
    > ...), but I barely know the 'common' use of the environment.
    >
    > My concern is that I need some local processes to communicate to a
    > local server. Now I use a SOCK_STREAM PF_UNIX in a path in /tmp, where
    > I suppose I can write. I think it's something I can suppose in a POSIX
    > system, but not in plan9.
    > How would you connect local processes (which can be launched at any
    > time) with a central server in plan9? Making that central server serve
    > a filesystem, where the clients write/read?
    > If I knew what's the path I should follow, I could think more easily
    > on a proper API for POSIX and Plan9 for my program.
    >
    > I may not have not worked in plan9 enough to deserve your attention,
    > but I hope a quick answer (even in the form of "man ___") will not
    > take much time.
    >
    > btw, the program I'd like to be able to run in plan9 is
    > http://vicerveza.homeunix.net/~viric/soft/ts/ . I wrote it because I
    > couldn't find anything similar to fit my needs, and maybe in plan9 you
    > already have something quick-and-useful for that purpose, and 'ts'
    > would not make any sense in p9 now. That's also something I'd be glad
    > to know.
    >
    > Thanks in advance,
    > Lluís.
    >


    LLuis,

    Read the description. Am confused.

    You connect to s server with a 'terminal' (the client?)

    The 'client' awaits permission from the server to run the task.

    - But the task actually runs on the *client*?

    Shall we presume it is the equivalent of a Plan9 'CPU' then? Or?

    (i.e. plenty of RAM and CPU-cycles, but short on storage space.)

    - using the server for scheduling control & spooling the output?

    AFAIK Plan9 can do many "similar" things already.

    But I am missing an example or three of what you would actually use this for..
    370-155's aside, there may be sound reason why there is nothing similar...

    ;-)

    Bill



  3. Re: [9fans] Porting to plan9 / PF_UNIX

    2007/4/14, W B Hacker :
    > LLuis,
    >
    > Read the description. Am confused.
    >
    > You connect to s server with a 'terminal' (the client?)

    No. The client is also 'ts', as the server. Two processes from the
    same program, doing different tasks. The server maintains a batch
    queue of the commands queued by 'ts' clients.
    >
    > The 'client' awaits permission from the server to run the task.

    The server maintains the queue of the tasks to be run (in a simple list).
    >
    > - But the task actually runs on the *client*?

    The task (the queued command) will be forked and execed from the
    client, once it received the server message allowing the task to be
    run (so, all previous tasks in the queue were accomplished)
    >
    > Shall we presume it is the equivalent of a Plan9 'CPU' then? Or?

    I don't think it's any similar at all.
    >
    > (i.e. plenty of RAM and CPU-cycles, but short on storage space.)
    >
    > - using the server for scheduling control & spooling the output?

    The server knows to what file the output is stored. And it 'spools'
    the tasks. I wouldn't use the verb 'schedule' for spooling.
    >
    > AFAIK Plan9 can do many "similar" things already.
    >
    > But I am missing an example or three of what you would actually use this for..
    > 370-155's aside, there may be sound reason why there is nothing similar....

    What are 370 and 155?

    Maybe you could look at the manpage of 'ts' for more information.

    Regards,
    Lluís.

  4. Re: [9fans] Porting to plan9 / PF_UNIX

    There is nothing in Plan 9 like a named socket.
    There is /srv, which is like named pipes (the
    difference is that named sockets distinguish
    multiple connections to them).

    If ts were a Plan 9 program, it would present a
    file tree that could be manipulated to add things
    to the queue or remove them or check their status,
    instead of inventing a custom RPC protocol.
    Then it would post a fd in /srv for 9P service,
    and you'd mount /srv/ts /mnt/ts and then interact
    with /mnt/ts via file operations. (Multiple programs
    can mount /srv/ts because the kernel acts as a
    multiplexor for 9P services -- the server sees only
    one 9P conversation.)

    Russ


  5. Re: [9fans] Porting to plan9 / PF_UNIX

    2007/4/14, Russ Cox :
    > There is nothing in Plan 9 like a named socket.
    > There is /srv, which is like named pipes (the
    > difference is that named sockets distinguish
    > multiple connections to them).

    That agrees with what I knew. I could not fit the sockets' multiple
    connections with srv.
    >
    > If ts were a Plan 9 program, it would present a
    > file tree that could be manipulated to add things
    > to the queue or remove them or check their status,
    > instead of inventing a custom RPC protocol.
    > Then it would post a fd in /srv for 9P service,
    > and you'd mount /srv/ts /mnt/ts and then interact
    > with /mnt/ts via file operations. (Multiple programs
    > can mount /srv/ts because the kernel acts as a
    > multiplexor for 9P services -- the server sees only
    > one 9P conversation.)

    That's exactly the kind of answer I was asking for. Thank you.

    In 'ts', the server does some tasks (has the task list, results.,) and
    the client does some others. The most important task (fork and exec
    the queued commad) must be necessarily be run from the client, so all
    the environment/namespace are kept.

    What I feel common from the plan9 file servers I've seen by now is
    that the server does all the processing, and mostly provides the
    filesystem as an interface to the user. Thus, being the server the
    process doing all the concerned tasks.

    Now I still cannot image what kind of files/directories 'ts' should
    serve to offer a good interface to the user, and how 'enqueuing'
    should work, getting a nice 'RPC' through that filesystem.
    I'll think of it, sure.

    Thanks!

  6. Re: [9fans] Porting to plan9 / PF_UNIX

    Lluís Batlle wrote:
    > 2007/4/14, W B Hacker :
    >> LLuis,

    *snip*

    >> But I am missing an example or three of what you would actually use
    >> this for..
    >> 370-155's aside, there may be sound reason why there is nothing
    >> similar...

    > What are 370 and 155?


    One of a family of IBM systems for turning batch processing into cash.
    Quite a lot of it from 1964 to the present day.

    >
    > Maybe you could look at the manpage of 'ts' for more information.
    >


    You describe a method, but not a specific application that benefits from it.

    Some - pehaps *all* of what you need to accomplish should be 'doable' within the
    existing Plan9 toolset

    - just not in quite the same manner as in either the Unix or '370 compatible'
    worlds..

    Bill

  7. Re: [9fans] Porting to plan9 / PF_UNIX

    On 4/14/07, Lluís Batlle wrote:

    >
    > Now I still cannot image what kind of files/directories 'ts' should
    > serve to offer a good interface to the user, and how 'enqueuing'
    > should work, getting a nice 'RPC' through that filesystem.
    > I'll think of it, sure.



    Liuis, I did something like this for the 9grid, for taskbags. I've
    also written similar tools for Unix over the years, so I think I see
    what you are up to. It's not identical to ts, just similar in nature.

    The server I wrote for Plan 9 was originally a port of the TNT work
    described here:
    http://arxiv.org/PS_cache/astro-ph/p.../9912134v1.pdf. The TNT
    server maintained task state describing work to be done, and
    mutiplexed that work to clients. One of the nice things about TNT, not
    mentioned in the paper, is that it supports "third party" or middlemen
    clients, i.e. clients can become servers and grab a bunch of tasks to
    be handed out. This distribution can be important if you have enough
    nodes, and turn tasks over very frequently. Also, of course, clients
    can put new work back into the bag of tasks. The work to be done was
    communicated to the server to/from clients via RPC (SunRPC). So, I
    began to do a straight conversion of this Unix socket-based server to
    Plan 9; about 10 minutes into the job, I realized I was not thinking
    about the problem correctly.

    I thought about what I would do if starting from scratch, on Plan 9.
    Plan 9 makes writing servers so easy that I went that route. I dumped
    the RPC-based model and created a server that represented the state of
    the work as directories and files. Basically, the server has three
    directories, questions, working, and answers. You put questions into
    the questions directory by opening and writing a file. To pass your
    'namespace', you could do an ns command into the questions file you
    created, then put the work in as a set of commands or rc script into
    that file. Each new piece of work is a new file.
    Clients start working by opening a questions file. Once a client has
    opened a questions file, subsequent 'ls' commands will show that file
    in the working directory, not the questions directory. To see what
    work is being done, you ls the working directory. Once a process is
    done, it closes the file; at that point, the file will appear in the
    answers directory, IF it has been written to. If the file was not
    written to, it reappears in the questions directory (this is to handle
    the case of clients that die). To see the answers to date, ls answers
    or cat answers/*. If you want programs to find out when work is
    completed,you could extend the server by having it create a 'status'
    file at the top level; programs can read that and block on it, and
    your server can distribute status info to as jobs are done.

    With this new Plan 9 server, I was able to do distributed computation
    entirely with shell scripts.

    One old problem with task bags related to multiple users. What if more
    than one user writes the task bag? This has been solved in complex
    ways on Unixen, with authentication happening on the server so that
    only the 'right' people get to the socket. This is solved trivially in
    Plan 9 -- each user, needing this service, starts a task bag server --
    problem solved.

    The beauty of a server is that you can stop thinking in terms of RPC!
    The "files" create a structure that is normally done in RPC. So, on
    Plan 9, try to avoid falling into old Unix patterns. If you start
    thinking in terms of a 'server' socket, and not a 9p server, and if
    you start writing RPC code, the odds are good that you are not
    approaching the problem correctly.

    I ported a few HPC computations to my taskbag server; it was pretty
    trivial. I *think* I left the code on sources (man 9fs to see what
    this statement means) in the 9grid directory; you can look.

    BTW, this sort of 'file-based' task bag idea has been done to death as
    well, usually on NFS and with a huge boatload of scripts to go with
    it. One system I saw, for MPEG encoding, had a 100-page (or so) script
    to use NFS files for holding tasks. 99 pages were for dealing with the
    problems that come with using NFS for this purpose ... not being able
    to guarantee exclusive create, open, and remove makes these things
    messy.

    It's not just the idea of using files to describe work that is so
    effective; it's the fact that the operations on the files are under
    control of your server, and hence they're not really files, but a
    representation of the work, shown to you as files. This disctinction
    is very important. It's why a Plan 9 task bag server can work, and the
    NFS-based task bag servers fail, and fail badly.

    It's nice to have you involved in Plan 9; welcome aboard. Don't
    hesitate to ask questions. It will be nice to see what you create.

    thanks

    ron

  8. Re: [9fans] Porting to plan9 / PF_UNIX

    I am not sure how I would use this, so my ideas of an appropriate interface
    are probably a bit off. For what it's worth, I would imagine a file system
    like the one mounted on /proc. One subdirectory per process. The files in
    the subdirectory would vary a bit depending on whether the job is finished,
    running or queued. In addition to the numbered directories there would
    be a special directory next, containing only the args file. Writing to
    /queue/next/args would create a job, which would then appear as a numbered
    directory like all the others. Feel free to ignore any of this if it
    doesn't fit your idea of what the spooler is for.

    John

    ps Since I started writing this, Ron's answer has appeared. It may well
    be a better idea, since he has actually implemented it and therefore
    knows where the pitfalls are.


    > I'm the developer of a Unix program that may be useful in plan9, and
    > as an exercise, I'd like it to build in plan9 native.
    >
    > Now, I've written it assuming POSIX (int signals, PF_UNIX available,
    > BSD sockets API, ...). I know more or less some details on plan9 (per
    > process namespaces, network not in a library to link with, notes,
    > ...), but I barely know the 'common' use of the environment.
    >
    > My concern is that I need some local processes to communicate to a
    > local server. Now I use a SOCK_STREAM PF_UNIX in a path in /tmp, where
    > I suppose I can write. I think it's something I can suppose in a POSIX
    > system, but not in plan9.
    > How would you connect local processes (which can be launched at any
    > time) with a central server in plan9? Making that central server serve
    > a filesystem, where the clients write/read?
    > If I knew what's the path I should follow, I could think more easily
    > on a proper API for POSIX and Plan9 for my program.
    >
    > I may not have not worked in plan9 enough to deserve your attention,
    > but I hope a quick answer (even in the form of "man ___") will not
    > take much time.
    >
    > btw, the program I'd like to be able to run in plan9 is
    > http://vicerveza.homeunix.net/~viric/soft/ts/ . I wrote it because I
    > couldn't find anything similar to fit my needs, and maybe in plan9 you
    > already have something quick-and-useful for that purpose, and 'ts'
    > would not make any sense in p9 now. That's also something I'd be glad
    > to know.
    >
    > Thanks in advance,
    > Llu=EDs.

    --
    John Stalker
    School of Mathematics
    Trinity College Dublin
    tel +353 1 896 1983
    fax +353 1 896 2282

  9. Re: [9fans] Porting to plan9 / PF_UNIX

    2007/4/14, ron minnich :
    > On 4/14/07, Lluís Batlle wrote:
    >
    > >
    > > Now I still cannot image what kind of files/directories 'ts' should
    > > serve to offer a good interface to the user, and how 'enqueuing'
    > > should work, getting a nice 'RPC' through that filesystem.
    > > I'll think of it, sure.

    >
    >
    > The server I wrote for Plan 9 was originally a port of the TNT work
    > described here:
    > http://arxiv.org/PS_cache/astro-ph/p.../9912134v1.pdf. The TNT
    > server maintained task state describing work to be done, and
    > mutiplexed that work to clients. One of the nice things about TNT, not
    > mentioned in the paper, is that it supports "third party" or middlemen
    > clients, i.e. clients can become servers and grab a bunch of tasks to
    > be handed out. This distribution can be important if you have enough
    > nodes, and turn tasks over very frequently. Also, of course, clients
    > can put new work back into the bag of tasks. The work to be done was
    > communicated to the server to/from clients via RPC (SunRPC). So, I
    > began to do a straight conversion of this Unix socket-based server to
    > Plan 9; about 10 minutes into the job, I realized I was not thinking
    > about the problem correctly.

    I was almost certain that I should rethink the whole program again,
    and although I may use some kind of RPC in unix (for avoiding linking
    against p9p libs), I should be able to provide an API independant from
    RPC or file servers.
    But having some code written in that direction would make me more sure
    of my words.
    >
    > I thought about what I would do if starting from scratch, on Plan 9.
    > Plan 9 makes writing servers so easy that I went that route. I dumped
    > the RPC-based model and created a server that represented the state of
    > the work as directories and files. Basically, the server has three
    > directories, questions, working, and answers. You put questions into
    > the questions directory by opening and writing a file. To pass your
    > .....

    I'd like to know what kind of file the "task submitter" should open.
    Did you have several names in the questions directory, and each
    submitter took one at random? It should be a name not colliding with
    others in working or answers...
    Or maybe the submitter opened a file with _any_ name (altough no 'ls'
    would show it in questions), and that was created with the same name
    in working?
    >
    > One old problem with task bags related to multiple users. What if more
    > than one user writes the task bag? This has been solved in complex
    > ways on Unixen, with authentication happening on the server so that
    > only the 'right' people get to the socket. This is solved trivially in
    > Plan 9 -- each user, needing this service, starts a task bag server --
    > problem solved.

    Also in my 'ts' each user has (in general) its own server. It depends
    on the socket path they use. On agreement among users, they can use a
    common socket with proper unix socket permissions in the filesystem.
    >
    > The beauty of a server is that you can stop thinking in terms of RPC!
    > The "files" create a structure that is normally done in RPC. So, on
    > Plan 9, try to avoid falling into old Unix patterns. If you start
    > thinking in terms of a 'server' socket, and not a 9p server, and if
    > you start writing RPC code, the odds are good that you are not
    > approaching the problem correctly.

    I agree. But RPC may be as awful as lazy I am, and the file structure
    requires more thinking to find a nice solution - it will be probably
    published to users
    >
    > I ported a few HPC computations to my taskbag server; it was pretty
    > trivial. I *think* I left the code on sources (man 9fs to see what
    > this statement means) in the 9grid directory; you can look.

    I looked at /n/sources/9grid, but I could only find some code for xcpu
    there. Nothing named 'task bags' at first glance.
    >
    > BTW, this sort of 'file-based' task bag idea has been done to death as
    > well, usually on NFS and with a huge boatload of scripts to go with
    > it. One system I saw, for MPEG encoding, had a 100-page (or so) script
    > to use NFS files for holding tasks. 99 pages were for dealing with the
    > problems that come with using NFS for this purpose ... not being able
    > to guarantee exclusive create, open, and remove makes these things
    > messy.

    Well, my purpose on ts has never been multiuser queues for different
    computers. I thought it for the case a user knows the
    multitasking-limits of the resources of a single computer. Using hard
    disk heavily in two applications may slowdown both. Using at once two
    applications each requiring the amount of physical ram in the
    computer, may also slow/bring down the system. That's what ts was
    meant for.
    >
    > It's not just the idea of using files to describe work that is so
    > effective; it's the fact that the operations on the files are under
    > control of your server, and hence they're not really files, but a
    > representation of the work, shown to you as files. This disctinction
    > is very important. It's why a Plan 9 task bag server can work, and the
    > NFS-based task bag servers fail, and fail badly.

    Sure. I barely can believe someone tried such a thing over NFS.
    >
    > It's nice to have you involved in Plan 9; welcome aboard. Don't
    > hesitate to ask questions. It will be nice to see what you create.

    Having seen code in the operating system, read some works from Pike
    and Kernighan, watched the discussions in this list from a long time,
    it'd be a honor contributing a bit to the OS.
    But I cannot guarantee code in short term. My university project is
    entirely for another computing field and I should work on it, my job,
    and other studies grab my time in own elected priority. I can't say
    that I _need_ ts in plan9 (I mostly use p9p and not the OS). But it's
    a direction I'd like to move on.

    I'll also consider the nice and simple idea from John Stalker.

    Thank you for your inspiring and couraging messages,
    Lluís

+ Reply to Thread