[9fans] cpu vs ocpu and talking to 9p1 clients.

[9fans] cpu vs ocpu and talking to 9p1 clients.

[Dan Cross]

Putting together a CPU server recently, I found that drawterm couldn't
talk to it.  That was weird, I thought, since I knew that srvold9p would
be sort of automatigically injected into the middle of things to make
it work.  Investigating further, I found that /rc/bin/service/tcp1700^(5 6)
were trying to invoke something called /bin/ocpu, which doesn't exist.
Changing these scripts to look like, ``#!/bin/cpu -O'' seems to have
fixed the problem, though I find that I still can't get to /mnt/term,
(this is from FreeBSD, by the way) which is a major, serious, bummer.
Oh well, worse things have happened.

	- Dan C.

Re: [9fans] cpu vs ocpu and talking to 9p1 clients.

[andrey mirtchovski]

On Mon, 13 Jan 2003, Dan Cross wrote:

> fixed the problem, though I find that I still can't get to /mnt/term,
> (this is from FreeBSD, by the way) which is a major, serious, bummer.


see if you can cd to /mnt/term/home/$user directly, or try
cd-ing to /mnt/term/stand for example...

i had the same problem just yesterday and found that 'du -a' was able
to read /mnt/term while 'ls' was not...

andrey

Re: [9fans] cpu vs ocpu and talking to 9p1 clients.

[Russ Cox]

The reason ls fails while du -a works is that ls stats its
argument while du -a does not.  Drawterm returns "#/"
or something like that as the name when you stat /mnt/term,
which isn't legal.

Re: [9fans] cpu vs ocpu and talking to 9p1 clients.

[Russ Cox]

Drawterm talks on tcp17013.
Maybe that's your problem.

ocpu is very o.

Re: [9fans] cpu vs ocpu and talking to 9p1 clients.

[Dan Cross]

> Drawterm talks on tcp17013.

That's what I thought, and I had created tcp17013.  Maybe it had
to do with some other problems I was having at the same time with
keyfs (I mistyped the password when I initially started it, since
it couldn't find my nvram file; that caused all kinds of woe later
on until I ditched the keys file and recreated it from scratch).

> Maybe that's your problem.

No, I was just confused.  I saw that cpu() and noteproc() dialed
the old ports in drawterm.c, but neglected to notice that the
calls to those functions were commented out.  Mea cupla.

> ocpu is very o.

So is it fine to just remove tcp17005 and tcp17006 then?

	- Dan C.

Re: [9fans] cpu vs ocpu and talking to 9p1 clients.

[Skip Tavakkolian]

>> fixed the problem, though I find that I still can't get to /mnt/term,
>> (this is from FreeBSD, by the way) which is a major, serious, bummer.
> 
> 
> see if you can cd to /mnt/term/home/$user directly, or try
> cd-ing to /mnt/term/stand for example...
> 
> i had the same problem just yesterday and found that 'du -a' was able
> to read /mnt/term while 'ls' was not...

If this is the "bad character in file name #/", there is a work-around for it.
A variation of one that was suggested a while back, that I use is:

cpu% mkdir termdrive # assuming you don't have one already
cpu% bind -ac /mnt/term termdrive
cpu% lnfs termdrive # optional

A message a while back from Russ said that this was a known
bug.

Re: [9fans] cpu vs ocpu and talking to 9p1 clients.

[Dan Cross]

> If this is the "bad character in file name #/", there is a work-around for it.
> A variation of one that was suggested a while back, that I use is:
> 
> cpu% mkdir termdrive # assuming you don't have one already
> cpu% bind -ac /mnt/term termdrive
> cpu% lnfs termdrive # optional
> 
> A message a while back from Russ said that this was a known
> bug.

Thanks Skip, this is really helpful.  I now do this from my
profile when I'm invoked from drawterm:

	mntgen
	bind -ac /mnt/term /n/term

And then I'm good to go.  Thanks again!

	- Dan C.