9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* (no subject)
@ 2000-08-01 13:37 sah
  2000-08-01 14:53 ` [9fans] Re: your mail Lucio De Re
  0 siblings, 1 reply; 5+ messages in thread
From: sah @ 2000-08-01 13:37 UTC (permalink / raw)
  To: 9fans

Thanks to forsyth, the terms are up and running.  Three cheers.

Now I need to connect to the V2 fs to transfer important files over to
V3 so we can complete the 'upgrade.'  Attempts of 9fs to our V2 fs via a
V3 term return "mount: mount bootes: attach -- authentication failed."
Also, the V2 fs states "bad AuthTs num."  The passwords and usernames are
identical on both systems.

So close I can taste it,

Sam

--------------------------------------------------------------
Sam Hopkins
sah@borf.com

"... let us tame the savageness of man, and make
	gentle the life of this world."




^ permalink raw reply	[flat|nested] 5+ messages in thread

* [9fans] Re: your mail
  2000-08-01 13:37 sah
@ 2000-08-01 14:53 ` Lucio De Re
  0 siblings, 0 replies; 5+ messages in thread
From: Lucio De Re @ 2000-08-01 14:53 UTC (permalink / raw)
  To: 9fans

On Tue, Aug 01, 2000 at 09:37:52AM -0400, sah@borf.com wrote:
> 
> Now I need to connect to the V2 fs to transfer important files over to
> V3 so we can complete the 'upgrade.'  Attempts of 9fs to our V2 fs via a
> V3 term return "mount: mount bootes: attach -- authentication failed."
> Also, the V2 fs states "bad AuthTs num."  The passwords and usernames are
> identical on both systems.
> 
I'm running very successfully with 2ed AUTH and FS.  CPUs are somewhat
confused, and I can't quite get the 2ed AUTH to execute the mail stuff
on a 3ed CPU :-(

On the other hand, I'm not sure how a 2ed FS would handle 3ed AUTH,
which may be your problem.  Between a rock and a hard place, like me.
It may of course be merely a question of making sure AUTH and FS are
in the right type of sync, which presumably means the same password
for the FS and the AUTH uid.

I'll enable AUTH on the 3ed CPU server a little later, see what
confusion I can create.  In the meantime...

> So close I can taste it,
> 
... I think you just need a slightly longer tongue, that's all :-)

++L


^ permalink raw reply	[flat|nested] 5+ messages in thread

* [9fans] Re: your mail
  2003-10-20 10:33 [9fans] porting from vs. porting to Plan 9 Douglas A. Gwyn
@ 2003-10-21  0:10 ` Roman Shaposhnick
  0 siblings, 0 replies; 5+ messages in thread
From: Roman Shaposhnick @ 2003-10-21  0:10 UTC (permalink / raw)
  To: Douglas A. Gwyn; +Cc: 9fans

> Roman Shaposhnick wrote:
> >   I always wanted to see how many applications would break if I were to,
> >   lets say, disable shared memory from SysV API. It could be a nice
> >   experiment to do on a live contemporary distro -- just pick a set of
> >   obscure interfaces and see how many applications are really using
> >   any of it.
>
> Just because something isn't much used doesn't prove that
> it isn't essential to have for a few cases where it is used.
> In the case of shared memory, more recent apps use threads
> instead of separate processes sharing memory.  Threads
> weren't available when shared memory was added.

  And that's why it's important to find out how many applications
  out there are still using it. From my personal perspective,
  shm is not a good thing and it should be avoided.

  It's the same story when P9 (or should I say 9P) broke the
  long-standing promise of having a file around as long as
  you don't close it. Turned out -- not that many apps failed.
  Or so I was told, anyway.

Thanks,
Roman.


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [9fans] Re: your mail
@ 2000-08-02  1:24 presotto
  0 siblings, 0 replies; 5+ messages in thread
From: presotto @ 2000-08-02  1:24 UTC (permalink / raw)
  To: 9fans

[-- Attachment #1: Type: text/plain, Size: 2129 bytes --]

We changed the cpu protocol between editions.  The change was
to get rid of the second connection for notes.  This was a good
suggestion from Dave Mazieres at MIT.

You can convert the 2ed cpu.c to run on 3ed.  Here's the
diffs:

% diff cpu.c /sys/src/cmd/ocpu.c
21a22
> int	filter(int);
26a28
> int	fflag;
30,31c32,33
< char	*srvname = "cpu";
< char	*notesrv = "cpunote";
---
> char	*srvname = "ocpu";
> char	*notesrv = "ocpunote";
39a42
> int fdd;
50a54,56
> 	case 'f':
> 		fflag++;
> 		break;
109a116,118
> 	if(fflag)
> 		data = filter(data);
> 
124a134
> 	va_list arg;
126c136,138
< 	doprint(buf, buf+sizeof(buf), fmt, (&fmt+1));
---
> 	va_start(arg, fmt);
> 	doprint(buf, buf+sizeof(buf), fmt, arg);
> 	va_end(arg);
183a196
> 
185c198,202
< 	if(amount(fd, "/mnt/term", MREPL, "") < 0)
---
> 
> 	/* push fcall */
> 	if(fflag)
> 		fd = filter(fd);
> 	if(amount(fd, "/mnt/term", MCREATE|MREPL, "") < 0)
282a300
> 	char dir[4*NAMELEN];
285c303
< 	if((*fd = dial(na, 0, 0, 0)) < 0)
---
> 	if((*fd = dial(na, 0, dir, 0)) < 0)
288a307,308
> 	if(strstr(dir, "tcp"))
> 		fflag = 1;
318a339,366
> 
> /* Network on fd1, mount driver on fd0 */
> int
> filter(int fd)
> {
> 	int p[2];
> 
> 	if(pipe(p) < 0)
> 		fatal(1, "pipe");
> 
> 	switch(rfork(RFNOWAIT|RFPROC|RFFDG)) {
> 	case -1:
> 		fatal(1, "rfork record module");
> 	case 0:
> 		dup(fd, 1);
> 		close(fd);
> 		dup(p[0], 0);
> 		close(p[0]);
> 		close(p[1]);
> 		execl("/bin/aux/fcall", "fcall", 0);
> 		fatal(1, "exec record module");
> 	default:
> 		close(fd);
> 		close(p[0]);
> 	}
> 	return p[1];	
> }
> 

You also need to create the /rc/bin/service files on 3ed for
the 2ed ports:

% cat > /rc/bin/service/il17006 << EOF
#!/bin/rc
exec /bin/ocpu -R
EOF
% cat > /rc/bin/service/il17006 << EOF
#!/bin/ocpu -N
EOF
% cat > /rc/bin/service/tcp17005 << EOF
#!/bin/rc
exec /bin/ocpu -f -R
EOF
% cat > /rc/bin/service/tcp17006 << EOF
#!/bin/ocpu -N
EOF
% chmod +x /rc/bin/service/*1700[56]

You can then use ocpu to get back to 2ed.
I'll put these puppies in the next update.

[-- Attachment #2: Type: message/rfc822, Size: 2707 bytes --]

From: Lucio De Re <lucio@proxima.alt.za>
To: 9fans@cse.psu.edu
Subject: [9fans] Re: your mail
Date: Tue, 1 Aug 2000 16:53:42 +0200
Message-ID: <20000801165341.F4605@cackle.proxima.alt.za>

On Tue, Aug 01, 2000 at 09:37:52AM -0400, sah@borf.com wrote:
> 
> Now I need to connect to the V2 fs to transfer important files over to
> V3 so we can complete the 'upgrade.'  Attempts of 9fs to our V2 fs via a
> V3 term return "mount: mount bootes: attach -- authentication failed."
> Also, the V2 fs states "bad AuthTs num."  The passwords and usernames are
> identical on both systems.
> 
I'm running very successfully with 2ed AUTH and FS.  CPUs are somewhat
confused, and I can't quite get the 2ed AUTH to execute the mail stuff
on a 3ed CPU :-(

On the other hand, I'm not sure how a 2ed FS would handle 3ed AUTH,
which may be your problem.  Between a rock and a hard place, like me.
It may of course be merely a question of making sure AUTH and FS are
in the right type of sync, which presumably means the same password
for the FS and the AUTH uid.

I'll enable AUTH on the 3ed CPU server a little later, see what
confusion I can create.  In the meantime...

> So close I can taste it,
> 
... I think you just need a slightly longer tongue, that's all :-)

++L

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [9fans] Re: your mail
@ 2000-08-01 15:13 forsyth
  0 siblings, 0 replies; 5+ messages in thread
From: forsyth @ 2000-08-01 15:13 UTC (permalink / raw)
  To: 9fans

at vita nuova we run the 3rd edition on cpu server, cpu/auth server, and many terminals with a
second edition file server kernel, with authentication but without fuss.
i'm fairly sure i did not need to change anything.



^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2003-10-21  0:10 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-08-01 13:37 sah
2000-08-01 14:53 ` [9fans] Re: your mail Lucio De Re
2000-08-01 15:13 forsyth
2000-08-02  1:24 presotto
2003-10-20 10:33 [9fans] porting from vs. porting to Plan 9 Douglas A. Gwyn
2003-10-21  0:10 ` [9fans] Re: your mail Roman Shaposhnick

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