* [9fans] consterm @ 2007-11-06 18:08 Eric Van Hensbergen 2007-11-06 18:15 ` erik quanstrom ` (3 more replies) 0 siblings, 4 replies; 15+ messages in thread From: Eric Van Hensbergen @ 2007-11-06 18:08 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Has anyone done a term program to connect to Plan 9 or Inferno -- kinda like drawterm, without the draw bits? I guess I am thinking about something that exports /dev/cons, /mnt/term, /dev/audio, etc. -- but then just runs an rc on the other end instead of rio so I can just run it within an xterm (or whatever). Seems like it would be a useful thing to have. -eric ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [9fans] consterm 2007-11-06 18:08 [9fans] consterm Eric Van Hensbergen @ 2007-11-06 18:15 ` erik quanstrom 2007-11-06 18:23 ` Tim Wiess ` (2 subsequent siblings) 3 siblings, 0 replies; 15+ messages in thread From: erik quanstrom @ 2007-11-06 18:15 UTC (permalink / raw) To: 9fans > Has anyone done a term program to connect to Plan 9 or Inferno -- > kinda like drawterm, without the draw bits? I guess I am thinking > about something that exports /dev/cons, /mnt/term, /dev/audio, etc. -- > but then just runs an rc on the other end instead of rio so I can just > run it within an xterm (or whatever). Seems like it would be a useful > thing to have. > > -eric drawterm'll do that. just don't start rio. - erik ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [9fans] consterm 2007-11-06 18:08 [9fans] consterm Eric Van Hensbergen 2007-11-06 18:15 ` erik quanstrom @ 2007-11-06 18:23 ` Tim Wiess 2007-11-06 19:40 ` Skip Tavakkolian 2007-11-06 20:00 ` Russ Cox 3 siblings, 0 replies; 15+ messages in thread From: Tim Wiess @ 2007-11-06 18:23 UTC (permalink / raw) To: 9fans > Has anyone done a term program to connect to Plan 9 or Inferno -- > kinda like drawterm, without the draw bits? I guess I am thinking > about something that exports /dev/cons, /mnt/term, /dev/audio, etc. -- > but then just runs an rc on the other end instead of rio so I can just > run it within an xterm (or whatever). Seems like it would be a useful > thing to have. unless i'm mistaken, Russ started working on a cpu(1) equivalent for plan9ports awhile back... /n/sources/contrib/rsc/cpu.tar.gz % grep cpu /n/sources/contrib/rsc/INDEX cpu.tar.gz: beginnings of cpu for p9p ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [9fans] consterm 2007-11-06 18:08 [9fans] consterm Eric Van Hensbergen 2007-11-06 18:15 ` erik quanstrom 2007-11-06 18:23 ` Tim Wiess @ 2007-11-06 19:40 ` Skip Tavakkolian 2007-11-06 20:00 ` Russ Cox 3 siblings, 0 replies; 15+ messages in thread From: Skip Tavakkolian @ 2007-11-06 19:40 UTC (permalink / raw) To: 9fans > Has anyone done a term program to connect to Plan 9 or Inferno -- > kinda like drawterm, without the draw bits? I guess I am thinking > about something that exports /dev/cons, /mnt/term, /dev/audio, etc. -- > but then just runs an rc on the other end instead of rio so I can just > run it within an xterm (or whatever). Seems like it would be a useful > thing to have. not that i know of. even if you don't start rio, the machinary in gui-*/screen.c is used because devdraw is mounted. if it was done, it would be useful for developing a gizmo for exporting from a host os to Plan9 running inside QEMU. it would be easy then to make an exportfs-only version of drawterm, and make a version of cpu.c (remote side) that instead of mounting the authenticated fd on /mnt/term, it starts a pair of procs that relay between the fd and a pipe post to /srv. dt's ns can then be mounted anywhere. does the p9p cpu handle authentication? ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [9fans] consterm 2007-11-06 18:08 [9fans] consterm Eric Van Hensbergen ` (2 preceding siblings ...) 2007-11-06 19:40 ` Skip Tavakkolian @ 2007-11-06 20:00 ` Russ Cox 2007-11-06 21:43 ` Eric Van Hensbergen 3 siblings, 1 reply; 15+ messages in thread From: Russ Cox @ 2007-11-06 20:00 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On 11/6/07, Eric Van Hensbergen <ericvh@gmail.com> wrote: > Has anyone done a term program to connect to Plan 9 or Inferno -- > kinda like drawterm, without the draw bits? I guess I am thinking > about something that exports /dev/cons, /mnt/term, /dev/audio, etc. -- > but then just runs an rc on the other end instead of rio so I can just > run it within an xterm (or whatever). Seems like it would be a useful > thing to have. It is trivial to rip the gui out of drawterm and make reads and writes to /dev/cons redirect to reads and writes on /dev/tty instead of the graphics console. Patch below. There is no p9p cpu, only the very very sketchy beginnings. You're much better off starting with drawterm, especially if you want things like /dev/audio. Russ diff -c drawterm/Makefile consterm/Makefile drawterm/Makefile:18,27 - consterm/Makefile:18,23 libauthsrv/libauthsrv.a\ libsec/libsec.a\ libmp/libmp.a\ - libmemdraw/libmemdraw.a\ - libmemlayer/libmemlayer.a\ - libdraw/libdraw.a\ - gui-$(GUI)/libgui.a\ libc/libc.a\ # stupid gcc drawterm/Makefile:55,71 - consterm/Makefile:51,55 libsec/libsec.a: (cd libsec; $(MAKE)) - libmemdraw/libmemdraw.a: - (cd libmemdraw; $(MAKE)) - - libmemlayer/libmemlayer.a: - (cd libmemlayer; $(MAKE)) - - libdraw/libdraw.a: - (cd libdraw; $(MAKE)) - libc/libc.a: (cd libc; $(MAKE)) - - gui-$(GUI)/libgui.a: - (cd gui-$(GUI); $(MAKE)) diff -c drawterm/kern/Makefile consterm/kern/Makefile drawterm/kern/Makefile:11,23 - consterm/kern/Makefile:11,21 devaudio.$O\ devaudio-$(AUDIO).$O\ devcons.$O\ - devdraw.$O\ devfs-$(OS).$O\ devip.$O\ devip-$(OS).$O\ devlfd.$O\ devmnt.$O\ - devmouse.$O\ devpipe.$O\ devroot.$O\ devssl.$O\ drawterm/kern/Makefile:35,41 - consterm/kern/Makefile:33,38 sysproc.$O\ qio.$O\ qlock.$O\ - term.$O\ uart.$O\ waserror.$O\ $(OS).$O diff -c drawterm/kern/devcons.c consterm/kern/devcons.c drawterm/kern/devcons.c:465,471 - consterm/kern/devcons.c:465,470 Qreboot, Qsecstore, Qshowfile, - Qsnarf, Qswap, Qsysname, Qsysstat, drawterm/kern/devcons.c:499,505 - consterm/kern/devcons.c:498,503 "reboot", {Qreboot}, 0, 0664, "secstore", {Qsecstore}, 0, 0666, "showfile", {Qshowfile}, 0, 0220, - "snarf", {Qsnarf}, 0, 0666, "swap", {Qswap}, 0, 0664, "sysname", {Qsysname}, 0, 0664, "sysstat", {Qsysstat}, 0, 0666, drawterm/kern/devcons.c:510,516 - consterm/kern/devcons.c:508,513 char secstorebuf[65536]; Dirtab *secstoretab = &consdir[Qsecstore]; - Dirtab *snarftab = &consdir[Qsnarf]; int readnum(ulong off, char *buf, ulong n, ulong val, int size) drawterm/kern/devcons.c:607,620 - consterm/kern/devcons.c:604,609 memset(secstorebuf, 0, sizeof secstorebuf); break; - case Qsnarf: - if(omode == ORDWR) - error(Eperm); - if(omode == OREAD) - c->aux = strdup(""); - else - c->aux = mallocz(SnarfSize, 1); - break; } return c; } drawterm/kern/devcons.c:640,651 - consterm/kern/devcons.c:629,634 qhangup(kprintoq, nil); } break; - - case Qsnarf: - if(c->mode == OWRITE) - clipwrite(c->aux); - free(c->aux); - break; } } drawterm/kern/devcons.c:751,765 - consterm/kern/devcons.c:734,739 case Qnull: return 0; - case Qsnarf: - if(offset == 0){ - free(c->aux); - c->aux = clipread(); - } - if(c->aux == nil) - return 0; - return readstr(offset, buf, n, c->aux); - case Qsecstore: return readstr(offset, buf, n, secstorebuf); drawterm/kern/devcons.c:919,931 - consterm/kern/devcons.c:893,898 case Qshowfile: return showfilewrite(a, n); - - case Qsnarf: - if(offset >= SnarfSize || offset+n >= SnarfSize) - error(Etoobig); - snarftab->qid.vers++; - memmove((uchar*)c->aux+offset, va, n); - return n; case Qsysstat: n = 0; diff -c drawterm/kern/devtab.c consterm/kern/devtab.c drawterm/kern/devtab.c:9,16 - consterm/kern/devtab.c:9,14 extern Dev pipedevtab; extern Dev ssldevtab; extern Dev tlsdevtab; - extern Dev mousedevtab; - extern Dev drawdevtab; extern Dev ipdevtab; extern Dev fsdevtab; extern Dev mntdevtab; drawterm/kern/devtab.c:23,30 - consterm/kern/devtab.c:21,26 &pipedevtab, &ssldevtab, &tlsdevtab, - &mousedevtab, - &drawdevtab, &ipdevtab, &fsdevtab, &mntdevtab, diff -c drawterm/main.c consterm/main.c drawterm/main.c:9,14 - consterm/main.c:9,16 char *argv0; char *user; + void ttyinit(void); + extern int errfmt(Fmt*); void sizebug(void) drawterm/main.c:40,57 - consterm/main.c:42,55 osinit(); procinit0(); printinit(); - screeninit(); chandevreset(); chandevinit(); quotefmtinstall(); + ttyinit(); if(bind("#c", "/dev", MBEFORE) < 0) panic("bind #c: %r"); - if(bind("#m", "/dev", MBEFORE) < 0) - panic("bind #m: %r"); - if(bind("#i", "/dev", MBEFORE) < 0) - panic("bind #i: %r"); if(bind("#I", "/net", MBEFORE) < 0) panic("bind #I: %r"); if(bind("#U", "/", MAFTER) < 0) drawterm/main.c:122,126 - consterm/main.c:120,151 return pass; } return nil; + } + + #undef read + #undef write + #undef system + + void + ttyputs(char *s, int n) + { + write(1, s, n); + } + + void + ttyreader(void *arg) + { + char c; + + system("stty raw; stty -echo"); + while(read(0, &c, 1) == 1) + kbdputc(kbdq, c&0xff); + } + + void + ttyinit(void) + { + screenputs = ttyputs; + kproc("tty", ttyreader, 0); } ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [9fans] consterm 2007-11-06 20:00 ` Russ Cox @ 2007-11-06 21:43 ` Eric Van Hensbergen 2007-11-06 22:39 ` Uriel 0 siblings, 1 reply; 15+ messages in thread From: Eric Van Hensbergen @ 2007-11-06 21:43 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On 11/6/07, Russ Cox <rsc@swtch.com> wrote: > On 11/6/07, Eric Van Hensbergen <ericvh@gmail.com> wrote: > > Has anyone done a term program to connect to Plan 9 or Inferno -- > > kinda like drawterm, without the draw bits? I guess I am thinking > > about something that exports /dev/cons, /mnt/term, /dev/audio, etc. -- > > but then just runs an rc on the other end instead of rio so I can just > > run it within an xterm (or whatever). Seems like it would be a useful > > thing to have. > > It is trivial to rip the gui out of drawterm and make reads and > writes to /dev/cons redirect to reads and writes on /dev/tty > instead of the graphics console. Patch below. > > There is no p9p cpu, only the very very sketchy beginnings. > You're much better off starting with drawterm, especially if > you want things like /dev/audio. > Cool - kinda figured it would be easy to mod drawterm, just wondering if someone had already done it. Thanks Russ. -eric ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [9fans] consterm 2007-11-06 21:43 ` Eric Van Hensbergen @ 2007-11-06 22:39 ` Uriel 2007-11-06 22:54 ` Eric Van Hensbergen 0 siblings, 1 reply; 15+ messages in thread From: Uriel @ 2007-11-06 22:39 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Why not just use Inferno? Caerwyn posted two lines that can be run on an inferno terminal and will 'cpu' into a plan9 box. I'm more and more convinced that maintaining drawterm is a waste of resources and it should be replaced with an Inferno package (ala acme-sac) that does the same thing reusing the already existing functionality in Inferno. uriel On Nov 6, 2007 10:43 PM, Eric Van Hensbergen <ericvh@gmail.com> wrote: > On 11/6/07, Russ Cox <rsc@swtch.com> wrote: > > On 11/6/07, Eric Van Hensbergen <ericvh@gmail.com> wrote: > > > Has anyone done a term program to connect to Plan 9 or Inferno -- > > > kinda like drawterm, without the draw bits? I guess I am thinking > > > about something that exports /dev/cons, /mnt/term, /dev/audio, etc. -- > > > but then just runs an rc on the other end instead of rio so I can just > > > run it within an xterm (or whatever). Seems like it would be a useful > > > thing to have. > > > > It is trivial to rip the gui out of drawterm and make reads and > > writes to /dev/cons redirect to reads and writes on /dev/tty > > instead of the graphics console. Patch below. > > > > There is no p9p cpu, only the very very sketchy beginnings. > > You're much better off starting with drawterm, especially if > > you want things like /dev/audio. > > > > Cool - kinda figured it would be easy to mod drawterm, just wondering > if someone had already done it. Thanks Russ. > > -eric > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [9fans] consterm 2007-11-06 22:39 ` Uriel @ 2007-11-06 22:54 ` Eric Van Hensbergen 2007-11-06 23:35 ` erik quanstrom 0 siblings, 1 reply; 15+ messages in thread From: Eric Van Hensbergen @ 2007-11-06 22:54 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On 11/6/07, Uriel <uriel99@gmail.com> wrote: > Why not just use Inferno? Caerwyn posted two lines that can > be run on an inferno terminal and will 'cpu' into a plan9 box. > I'm looking for something lighter weight than Inferno or full-blown Drawterm -- something that lets me 'cpu' from an xterm is just about right -- and I can accept using a 'consterm' version of drawterm to get that light-weight access. Part of this is personal laziness -- I usually need to get in and out to copy files, which I could do if I just used a proper v9fs setup plus factotum. I actually wanted one of these for Inferno as well - we were using a single Inferno instance to manage multiple libOS partitions - it seemed kind of silly to start up other Inferno partitions just to launch applications on the "controller" Inferno. I ended up working around this in another way, but something like cpu would have been preferable. However, I'm also thinking longer term - towards the FastOS project where users aren't going to necessarily want to fire up a whole 'environment' such as Inferno or Drawterm just to execute an application on the cluster -- particularly if that application isn't graphical. -eric ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [9fans] consterm 2007-11-06 22:54 ` Eric Van Hensbergen @ 2007-11-06 23:35 ` erik quanstrom 2007-11-06 23:53 ` arisawa 2007-11-07 0:28 ` Eric Van Hensbergen 0 siblings, 2 replies; 15+ messages in thread From: erik quanstrom @ 2007-11-06 23:35 UTC (permalink / raw) To: 9fans > However, I'm also thinking longer term - towards the FastOS project > where users aren't going to necessarily want to fire up a whole > 'environment' such as Inferno or Drawterm just to execute an > application on the cluster -- particularly if that application isn't > graphical. i think i don't understand your problem, as drawterm runs on the host, not the client. if you had one cpuserver, you could cpu into the target nodes without starting very much on them. why won't that work? if you don't need to copy files around, telnet is even lighter weight. - erik ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [9fans] consterm 2007-11-06 23:35 ` erik quanstrom @ 2007-11-06 23:53 ` arisawa 2007-11-07 0:28 ` Eric Van Hensbergen 1 sibling, 0 replies; 15+ messages in thread From: arisawa @ 2007-11-06 23:53 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs I would like to have an option for drawterm to bypass graphical interface. I sometimes feel annoying the interface. Kenji Arisawa On 2007/11/07, at 8:35, erik quanstrom wrote: >> However, I'm also thinking longer term - towards the FastOS project >> where users aren't going to necessarily want to fire up a whole >> 'environment' such as Inferno or Drawterm just to execute an >> application on the cluster -- particularly if that application isn't >> graphical. > > i think i don't understand your problem, as drawterm runs on the host, > not the client. if you had one cpuserver, you could cpu into the > target nodes without starting very much on them. why won't that work? > > if you don't need to copy files around, telnet is even lighter weight. > > - erik ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [9fans] consterm 2007-11-06 23:35 ` erik quanstrom 2007-11-06 23:53 ` arisawa @ 2007-11-07 0:28 ` Eric Van Hensbergen 2007-11-07 3:51 ` matt 2007-11-07 5:29 ` ron minnich 1 sibling, 2 replies; 15+ messages in thread From: Eric Van Hensbergen @ 2007-11-07 0:28 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Nov 6, 2007 5:35 PM, erik quanstrom <quanstro@quanstro.net> wrote: > > However, I'm also thinking longer term - towards the FastOS project > > where users aren't going to necessarily want to fire up a whole > > 'environment' such as Inferno or Drawterm just to execute an > > application on the cluster -- particularly if that application isn't > > graphical. > > i think i don't understand your problem, as drawterm runs on the host, > not the client. if you had one cpuserver, you could cpu into the > target nodes without starting very much on them. why won't that work? > Its more of a perceived weight rather than an actual weight (perhaps that's bogus, but we are trying to win hearts as well as minds - so keeping things for end-users as familiar as possible is desirable). We want to maintain the appearance of things being transparent (like with cpu) -- not have a framebuffer automagically pop up. Having back access to files and environment is something we want to maintain (along with auth) so telnet isn't really an option. jmk points out there are other issues with this approach, but I feel confident we can create a tighter coupling between legacy systems and Plan 9/Inferno. -eric ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [9fans] consterm 2007-11-07 0:28 ` Eric Van Hensbergen @ 2007-11-07 3:51 ` matt 2007-11-07 3:55 ` matt 2007-11-07 5:29 ` ron minnich 1 sibling, 1 reply; 15+ messages in thread From: matt @ 2007-11-07 3:51 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs emu is a console app There's also a route that could use qemu as a user app. :> I tried running bind /dev/eia0 /dev/cons while() { auth/factotum echo host user resp = `{read} cpu -h $resp(1) $resp(2) } But after it gets your credentials it sends \r instead of \n when pressing enter Then I found consolefs which looks like it does the right thing but I didn't have the heart to try it out on what is probably a waste of time just to post it here. There's an idea there that I'm sure could get you xterm <> cpu <> node without writing too much more code :) ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [9fans] consterm 2007-11-07 3:51 ` matt @ 2007-11-07 3:55 ` matt 0 siblings, 0 replies; 15+ messages in thread From: matt @ 2007-11-07 3:55 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs cpu -h $resp(1) -u $resp(2) is what my code actually was ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [9fans] consterm 2007-11-07 0:28 ` Eric Van Hensbergen 2007-11-07 3:51 ` matt @ 2007-11-07 5:29 ` ron minnich 2007-11-07 5:48 ` andrey mirtchovski 1 sibling, 1 reply; 15+ messages in thread From: ron minnich @ 2007-11-07 5:29 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs I use xcpu for a lot of what you are talking about. I'm using it now on a small PNFS cluster I built. If I want interactive access ... xcpu <some nodes> /bin/bash done. And the bash comes from my machine so, if the nodes are busybox nodes (they usually are) then I need not worry that they don't have my binaries. But, that said, I keep cursing my bad luck in not having a real cpu on linux. I could use your consterm for things I'm doing. I'm finding that xcpu is fine for some things, but cpu really is nicer. I'm considering adding namespace support to xcpu so that when you start (e.g.) a shell via xcpu, once the shell starts up, its namespace is there. Hmm, I just recreated cpu -- save that I can run without the name space stuff -- it's optional. And, cpu doesn't do the nice tree spawn stuff that Lucho put into xcpu. Note that we did this on bproc, 5 years ago, and it was pretty nice. We could define the namespace for a process, and then start the process up on 1024 nodes and have them all start with the desired namespace. Handy! one thing you can't easily do on cpu, though, that xcpu is nice for: xcpu md,d1,d2,d3 fdisk /dev/sda (gets me 4 parallel interactive fdisk's on the four nodes md,d1,d2,d3 -- it seems weird but worked wonderfully well. cpu is just not set up to do this type of thing, and neither would your consterm be). It seems to me from watching it that the real weight in 'cpu' is in the all the stuff that gets run when you log in, not necessarily cpu itself. That's not too hard to get around. All this points (to me) to the fact that we have not really reached the final answer on the things we want to do with remote access. Or, maybe, there's no final answer at all. ron ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [9fans] consterm 2007-11-07 5:29 ` ron minnich @ 2007-11-07 5:48 ` andrey mirtchovski 0 siblings, 0 replies; 15+ messages in thread From: andrey mirtchovski @ 2007-11-07 5:48 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > (gets me 4 parallel interactive fdisk's on the four nodes md,d1,d2,d3 > -- it seems weird but worked wonderfully well. cpu is just not set up > to do this type of thing, and neither would your consterm be). we had a cpu that could talk to multiple nodes at the same time (multiplex i/o) in 2002, i believe. as well as an 'rx' that did the same thing. i'll dig through my fs, but chances are slim that i still have it. no idea why it didn't get much use. oh, wait, it was plan9-only :) ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2007-11-07 5:48 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-11-06 18:08 [9fans] consterm Eric Van Hensbergen 2007-11-06 18:15 ` erik quanstrom 2007-11-06 18:23 ` Tim Wiess 2007-11-06 19:40 ` Skip Tavakkolian 2007-11-06 20:00 ` Russ Cox 2007-11-06 21:43 ` Eric Van Hensbergen 2007-11-06 22:39 ` Uriel 2007-11-06 22:54 ` Eric Van Hensbergen 2007-11-06 23:35 ` erik quanstrom 2007-11-06 23:53 ` arisawa 2007-11-07 0:28 ` Eric Van Hensbergen 2007-11-07 3:51 ` matt 2007-11-07 3:55 ` matt 2007-11-07 5:29 ` ron minnich 2007-11-07 5:48 ` andrey mirtchovski
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).