[9fans] consterm

[9fans] consterm

[Eric Van Hensbergen]

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

Re: [9fans] consterm

[erik quanstrom]

> 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

Re: [9fans] consterm

[Tim Wiess]

> 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

Re: [9fans] consterm

[Skip Tavakkolian]

> 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?

Re: [9fans] consterm

[Russ Cox]

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);
  }

Re: [9fans] consterm

[Eric Van Hensbergen]

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

Re: [9fans] consterm

[Uriel]

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
>

Re: [9fans] consterm

[Eric Van Hensbergen]

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

Re: [9fans] consterm

[erik quanstrom]

> 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

Re: [9fans] consterm

[arisawa]

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

Re: [9fans] consterm

[Eric Van Hensbergen]

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

Re: [9fans] consterm

[matt]

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 :)

Re: [9fans] consterm

[matt]

cpu -h $resp(1) -u $resp(2)

is what my code actually was

Re: [9fans] consterm

[ron minnich]

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

Re: [9fans] consterm

[andrey mirtchovski]

> (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 :)