success with 9vx from a terminal - Plan9

This is a discussion on success with 9vx from a terminal - Plan9 ; Last night I downloaded 9vx. It works fine from a terminal, using the following invocation: .../9vx.Linux -g -u glenda where -g is the option to run sans GUI. This has one or two complications. There is no way to interrupt ...

+ Reply to Thread
Results 1 to 16 of 16

Thread: success with 9vx from a terminal

  1. success with 9vx from a terminal

    Last night I downloaded 9vx. It works fine from a terminal, using
    the following invocation:
    .../9vx.Linux -g -u glenda
    where -g is the option to run sans GUI.
    This has one or two complications. There is no way to interrupt or kill
    the foreground process. Instead, ctrl-c interrupts 9vx itself.
    Anyway, I managed to get an emulated Plan 9 system up and running.
    Both ed and "sam -d" work well for editing text.

    -- Chris

  2. Re: [9fans] success with 9vx from a terminal

    > This has one or two complications. There is no way to interrupt or kill
    > the foreground process. Instead, ctrl-c interrupts 9vx itself.


    chris,

    one of the nice things about the Plan 9 graphics system is that rio is
    in no way different than any other graphical program. it reads and
    writes files in /dev/wsys and multiplexes them between other
    applications. in that sense, you don't need to run rio in order to run
    a graphical app. from the 9vx console you can just type 'acme' and
    you'll have acme running in full-screen mode. if you know what you
    desire in a window manager (perhaps a terminal window in a static
    location to which you can always return, or keyboard-driven window
    switching) one can be written so that it's used instead of rio.
    graphical programs in plan9 are not hard.

    in the mean time you wan use acme's terminal (the program is called
    'win') to gain a more feature-full environment. i have attached here a
    dump file which can be used to start acme in a single-column mode with
    a single window running the terminal program. that will give you
    interrupt capability. from here you can hopefully explore the system
    without having to deal with windows. unfortunately the default for
    'win' is to not scroll to the bottom of the window when the text fills
    the screen and there is only one way to turn that off: in a terminal
    you have to type 'scroll' and middle-click it with the mouse (is there
    a way to issue this as a command from the terminal, anybody?). also,
    you can backspace over the beginning of the line to the previous row
    which can be annoying.

    if you think this may be useful and you want to give it a try please
    copy the attached acme.dump file somewhere within the 9vx plan9
    directory, then start 9vx and in its terminal type "acme -l
    /path/to/acme.dump" where /path/to is just the path relative to root.

    the screen will have acme's main "menu" (text) as its first row, then
    column menu as the second (New Cut Paste, etc) with the terminal
    starting on the third row.

    hope this gives you a better environment.

    andery


  3. Re: [9fans] success with 9vx from a terminal

    > you have to type 'scroll' and middle-click it with the mouse (is there
    > a way to issue this as a command from the terminal, anybody?). also,


    one would think that
    ; echo noscroll>/dev/wctl
    would work, but it does not.

    - erik


  4. Re: [9fans] success with 9vx from a terminal

    I was playing around with the modified "win" program and I realized
    it's not going to work due to the propensity of acme to redirect
    standard error to a separate window. This environment has no way of
    notifying anyone that a new window has opened without being requested
    except visually.

    A better solution would be to display only a single, border-less
    terminal window filling the entire screen. Perhaps even multiplexing
    between a few full-screen terminal windows similar to the ttys
    available on a *bsd or linux console.

    Sorry for the noise.


  5. Re: [9fans] success with 9vx from a terminal

    On Wed, 2008-10-22 at 10:54 -0600, andrey mirtchovski wrote:
    > > This has one or two complications. There is no way to interrupt or kill
    > > the foreground process. Instead, ctrl-c interrupts 9vx itself.

    >
    > chris,
    >
    > one of the nice things about the Plan 9 graphics system is that rio is
    > in no way different than any other graphical program. it reads and
    > writes files in /dev/wsys and multiplexes them between other
    > applications. in that sense, you don't need to run rio in order to run
    > a graphical app. from the 9vx console you can just type 'acme' and
    > you'll have acme running in full-screen mode. if you know what you
    > desire in a window manager (perhaps a terminal window in a static
    > location to which you can always return, or keyboard-driven window
    > switching) one can be written so that it's used instead of rio.
    > graphical programs in plan9 are not hard.
    >
    > in the mean time you wan use acme's terminal (the program is called
    > 'win') to gain a more feature-full environment.


    Everything up until this point made total sense to me. But now, that
    you've brought acme into discussion -- I'm confused. Granted, I happen
    to NOT be an acme user myself so may be that's why I see nothing that
    it brings to the table in this particular situation. The previous
    suggestion was around rio which, at face value was more than reasonable
    especially if one considers rio's desire to stay explicitly out of the
    way as far as drawing surfaces multiplexing is concerned:
    From rio(4):
    "Note that the draw(3) device multiplexes itself; rio places windows
    but does not mediate programs' access to the display device."
    It seems that all we need from rio(4) in a tty-only scenario is its
    ability to multiplex /dev/cons in a way that also interprets particular
    sequences of bytes (like Ctrl-C, Ctrl-D, and may be even escape
    sequences) and translates those into actions: sending a note to a
    process, creating a new window, etc. It almost sounds exactly like
    what screen(1) is doing for UNIX ttys. It probably will require
    some changes to the existing code for rio. That's what I would call an
    internal multiplexing: 9vx is running with its stdin, stdout and
    stderr attached to a tty and that's what gets served as '#c/cons'. The
    only process that accesses it is rio. The rest of the Plan 9 processes
    see /dev/cons served by rio. So far so good, except that 9vx *already*
    seems to interpret things like Ctrl-D:
    linux-box$ ./9vx.Linux -g -u glenda
    init: starting /bin/rc
    upas/fs: '/bin/upas/fs' does not exist
    #m/mousectl: rc: can't open: jmk added reentrancy for threads
    init: rc exit status: rc 5: error

    init: starting /bin/rc
    % cat
    %
    It looks like when I pressed Ctrl-D that got interpreted as an EOF
    coming from '#c/cons' right? In that same spirit, interpreting DEL
    as a character that triggers a note to be sent should also be quite
    doable within the #c driver. The only question is -- where such a note
    is supposed to be sent to?

    Can someone, please, educate me on the moral equivalent of process
    groups, sessions and their relationships with #c/cons ?

    Thanks,
    Roman.



  6. Re: [9fans] success with 9vx from a terminal

    On Thu, Oct 23, 2008 at 8:43 AM, Roman V. Shaposhnik wrote:
    > The only question is -- where such a note
    > is supposed to be sent to?
    >
    > Can someone, please, educate me on the moral equivalent of process
    > groups, sessions and their relationships with #c/cons ?


    Maybe you worked this one out already, but It depends on how they
    were forked. I don't think I can explain it better than rfork(2) - the
    bit about RFNOTEG is particularly relevant. I'm not aware of any
    relationship between #c/cons and notes, but I'm not really sure what
    magic is involved in the DEL interrupt.
    -sqweek


  7. Re: [9fans] success with 9vx from a terminal

    >I'm not really sure what magic is involved in the DEL interrupt.

    rio (or ip/telnetd, or ... some other user program).


  8. Re: [9fans] success with 9vx from a terminal

    On Mon, 2008-11-10 at 01:55 +0900, sqweek wrote:
    > On Thu, Oct 23, 2008 at 8:43 AM, Roman V. Shaposhnik wrote:
    > > The only question is -- where such a note
    > > is supposed to be sent to?
    > >
    > > Can someone, please, educate me on the moral equivalent of process
    > > groups, sessions and their relationships with #c/cons ?

    >
    > Maybe you worked this one out already,


    Well, sort of -- yes. But thanks for chiming in anyway.

    > I'm not aware of any relationship between #c/cons and notes,
    > but I'm not really sure what magic is involved in the DEL interrupt.


    At least in case of cpu(1) the magic is a bit perverse and quite
    unlike the rest of the system. The way notes are managed make
    a local end of a cpu(1) jump through considerable hoops in order
    for the notes to be properly delivered. That was a sad discovery.

    Another discovery was that devcons.c could have made DEL work
    but decided not to :-(

    Thanks,
    Roman.



  9. Re: [9fans] success with 9vx from a terminal

    On Mon, Nov 10, 2008 at 2:24 PM, Roman V. Shaposhnik wrote:

    > At least in case of cpu(1) the magic is a bit perverse and quite
    > unlike the rest of the system. The way notes are managed make
    > a local end of a cpu(1) jump through considerable hoops in order
    > for the notes to be properly delivered. That was a sad discovery.



    CPU is really worth reading and understanding. It uses a lot of neat
    tricks. Recommended.

    ron


  10. Re: [9fans] success with 9vx from a terminal

    On Mon, 2008-11-10 at 14:49 -0800, ron minnich wrote:
    > On Mon, Nov 10, 2008 at 2:24 PM, Roman V. Shaposhnik wrote:
    >
    > > At least in case of cpu(1) the magic is a bit perverse and quite
    > > unlike the rest of the system. The way notes are managed make
    > > a local end of a cpu(1) jump through considerable hoops in order
    > > for the notes to be properly delivered. That was a sad discovery.

    >
    >
    > CPU is really worth reading and understanding.


    100% agreed. But...

    > It uses a lot of neat tricks.


    .... would you really honestly say that rolling out your
    own notes forwarder is a *neat* trick? As opposed to
    be able to use basic system's FS functionality?

    This not a jab at cpu(1) rather at the design of notes.
    My personal feeling when going over that bit was: well,
    that's how UNIX people do signal forwarding (we do
    something similar for the remote debugging sessions)
    am I reading the right source file?!?!

    Thanks,
    Roman.



  11. Re: [9fans] success with 9vx from a terminal

    cpu is just great tutorial.

    notes forwarder, well, I am stil unsure.

    ron


  12. Re: [9fans] success with 9vx from a terminal

    > At least in case of cpu(1) the magic is a bit perverse and quite
    > unlike the rest of the system. The way notes are managed make
    > a local end of a cpu(1) jump through considerable hoops in order
    > for the notes to be properly delivered. That was a sad discovery.
    >
    > Another discovery was that devcons.c could have made DEL work
    > but decided not to :-(


    talking about it is the easy part. why don't you code something up?

    - erik



  13. Re: [9fans] success with 9vx from a terminal

    > ... would you really honestly say that rolling out your
    > own notes forwarder is a *neat* trick? As opposed to
    > be able to use basic system's FS functionality?


    ok, how would you implement it, then? how would you deliver a note to
    a process that's running on a remote machine? would you be introducing
    "distributed" notes in which you can specify a target machine as well
    as a target process? with special agents on the local host which can
    "dial" the remote machine to send it the note, and kernel daemon note
    forwarders which can accept notes from remote machines destined for
    local processes and... and..

    you run up the list of necessary (and required) services as quickly as
    portmap, rpc.idmapd and friends from nfs-land

    rmnoteproc() as implemented in cpu.c is just about the simplest way to
    do such a thing. it only requires one thing: the remote tree mounted
    in /mnt/term (which really is the clever bit). unfortunately we've
    been dealing with complexity in the non-plan9 world for so long that
    we are unable to appreciate anything unless it requires a huge deal of
    effort to comprehend


  14. Re: [9fans] success with 9vx from a terminal

    On Mon, 2008-11-10 at 16:42 -0700, andrey mirtchovski wrote:
    > > ... would you really honestly say that rolling out your
    > > own notes forwarder is a *neat* trick? As opposed to
    > > be able to use basic system's FS functionality?

    >
    > ok, how would you implement it, then? how would you deliver a note to
    > a process that's running on a remote machine?


    I would like to be able to import the /proc (or similar) filesystem from
    the remote machine and bind it over the files that my local kernel uses
    to send notes to the proxy process. That's how my "ideal world" model
    would work. Observe how that was also the first suggestion on the "notes
    thief" thread. Do you think it is a coincidence?

    > would you be introducing "distributed" notes in which you can specify a
    > target machine as well as a target process?


    Of course not! But I still would like *not* to be forced to invent
    a covert channel for things that really seem to belong to a devproc.c.

    Look, seriously, when cpu(1) is run inside a rio window the only reason
    it has to jump through these hoops is because rio sends notes using a
    notepg file located in a completely unrelated subdirectory in /proc.

    I'm not saying I know of a better way as of right now, all I'm saying
    is that notes and how the group of processes is handled by the Plan9
    kernel feels much less elegant than the rest of the system.

    > rmnoteproc() as implemented in cpu.c is just about the simplest way to
    > do such a thing.


    Given the constraints that I now understand notes require -- yes. But,
    honestly, don't you feel weird that /dev/cons gets proxied by a simple
    bind operation and notes are *the only* part of the system that need
    special handling?

    > it only requires one thing: the remote tree mounted in /mnt/term (which really
    > is the clever bit).


    Well it is the kind of cleverness that 9fans tend to dislike in other
    systems.

    Thanks,
    Roman.



  15. Re: [9fans] success with 9vx from a terminal

    > I would like to be able to import the /proc (or similar) filesystem from
    > the remote machine and bind it over the files that my local kernel uses
    > to send notes to the proxy process. That's how my "ideal world" model
    > would work. Observe how that was also the first suggestion on the "notes
    > thief" thread. Do you think it is a coincidence?


    if /proc is your only concern ask Jim or somebody else at BL to
    release the description of the original (plan9-only) cut of XCPU by
    Vic Zandy. I can't find my copy of it anymore and I don't remember if
    that information was releasable or not, but in short it was a modified
    p9 kernel that allowed you to start and control processes on multiple
    cpu servers at the same time.

    I don't remember if the solution for note sending across machines was
    novel. I seem to remember that in this case processes were addressed
    by node/pid.


  16. Re: [9fans] success with 9vx from a terminal

    On Mon, Nov 10, 2008 at 5:04 PM, andrey mirtchovski
    wrote:

    > I don't remember if the solution for note sending across machines was
    > novel. I seem to remember that in this case processes were addressed
    > by node/pid.
    >
    >


    I've got it somewhere, will rummage around.

    ron


+ Reply to Thread