Permissions on names served by the kernel

Permissions on names served by the kernel

[philw]

>I would like to see a discussion about unrelated namespace processes
>binding '#|" for IPC.  Does this work or does each bind create
>another pair of fd's?  There are some things about this local
>namespace that makes one feel uncomfortable.
look at devsrv

Permissions on names served by the kernel

[G.David]

Scott Schwartz <schwartz@galapagos.cse.psu.edu> writes:
|"G. David Butler" <gdb@dbSystems.com> writes:
|| I don't mind answers like RTFM or, in this case, RTFSource, but the source
|| you pointed me to has to do with the srv server (I guess, the code is
|| very terse and there are *NO* comments.)  I'm not quite sure what it was
|| you wanted me get out of this.
|
|/srv (really #s) is a place to plant open file descriptors so that
|other processes can find them.  I think looking at the manpage srv(3)
|would be more helpful than the source in this case.
|

Ah, the light goes on... :-)

[This is what happens when one has 15+ years UNIX experience to unlearn.]

So, the srv registry is a global space for an instance of a Plan9 kernel!

I will finish my lp stuff now...

Thanks!

db

Permissions on names served by the kernel

[philw]

devsrv and #s is what I pointed to. It is a means of
publishing services between namespaces. #s can pass
a channel to either a pipe or file system by posting
a name in a global place. The code to post a channel
is in srv.c but I meant look at the device driver.
8½ and other file servers make themselves available
using this mechanism. Files posted in srv can also
be opened and acessed remotely via srv. From a cpu
connection look at /mnt/term/srv. If you look at
/rc/bin/window you can see it work.

phil

Permissions on names served by the kernel

[G.David]

Regarding:

From: philw@plan9.att.com
To: 9fans@cse.psu.edu
Date: 	Wed, 20 Dec 1995 14:41:45 -0500
Subject: re: Permissions on names served by the kernel

>I would like to see a discussion about unrelated namespace processes
>binding '#|" for IPC.  Does this work or does each bind create
>another pair of fd's?  There are some things about this local
>namespace that makes one feel uncomfortable.
look at devsrv

[I have not had time to look into this again until now, so I have appended
my original mail to the end of this.]

I don't mind answers like RTFM or, in this case, RTFSource, but the source
you pointed me to has to do with the srv server (I guess, the code is
very terse and there are *NO* comments.)  I'm not quite sure what it was
you wanted me get out of this.

    Are you saying that #| is a server and thus any mount of it is separate?
    This would imply that there is *not* a way to have unrelated namespace
        processes use pipes as an IPC?

And while we're on it, if #| is a "server", why is there not an entry
in /srv for it and why don't you have to do a "mount" before the "bind"?

I have experimented more with #| and have found that separate binds do
in fact create a new pair of fd's.  So #| can't be used by unrelated
processes.

Does anybody have a suggestion has to how I should proceed?  I believe
there has to be a process started at cpu server boot, but I don't want
it to spin or sleep/spin on files in the queue (as if there was a way
to determine when the spooler was actually done....)

Thanks for your attention.

David Butler
gdb@dbSystems.com

====================================================================
Date: 	Wed, 20 Dec 1995 14:06:33 -0500
From: "G. David Butler" <gdb@dbSystems.com>
To: 9fans@cse.psu.edu
Subject: Permissions on names served by the kernel

Hi all!

I am running into an interesting problem.  I have been working on
getting the LP subsystem up using a PostScript printer connected
to the COM port of my PC cpu server.  It all works great (after
creating a "postio" and fixing lpdaemon) from the cpu server console.

When printing from a terminal (yes tcpsend works now) or from
a cpu window on the terminal,  the postio program can't do I/O to
/dev/eia0 since it doesn't have permissions.

The question.  How do you change the permissions of a file that is
served by the kernel?  Since the lpdaemon runs as "none" and the
permissions on #t/eia0 are 660 bootes bootes, it won't work.

Also, is there a problem binding something like '#t' in multiple
processes and doing I/O?

If the answer to the question is "you can't" (that is what it looks
like), it would seem my only alternative is to start up a process on
the cpuserver that keeps an eye on the print queue and fires up the
daemon.  Perhaps using pipe(3) to synchronize the spooler and daemon?

I would like to see a discussion about unrelated namespace processes
binding '#|" for IPC.  Does this work or does each bind create
another pair of fd's?  There are some things about this local
namespace that makes one feel uncomfortable.

If anyone has a better idea or a different view of the whole issue,
I would appreciate any input.

(As soon as I get it all to work, I will make it available.)

Thanks.

db

Permissions on names served by the kernel

[G.David]

Hi all!

I am running into an interesting problem.  I have been working on
getting the LP subsystem up using a PostScript printer connected
to the COM port of my PC cpu server.  It all works great (after
creating a "postio" and fixing lpdaemon) from the cpu server console.

When printing from a terminal (yes tcpsend works now) or from
a cpu window on the terminal,  the postio program can't do I/O to
/dev/eia0 since it doesn't have permissions.

The question.  How do you change the permissions of a file that is
served by the kernel?  Since the lpdaemon runs as "none" and the
permissions on #t/eia0 are 660 bootes bootes, it won't work.

Also, is there a problem binding something like '#t' in multiple
processes and doing I/O?

If the answer to the question is "you can't" (that is what it looks
like), it would seem my only alternative is to start up a process on
the cpuserver that keeps an eye on the print queue and fires up the
daemon.  Perhaps using pipe(3) to synchronize the spooler and daemon?

I would like to see a discussion about unrelated namespace processes
binding '#|" for IPC.  Does this work or does each bind create
another pair of fd's?  There are some things about this local
namespace that makes one feel uncomfortable.

If anyone has a better idea or a different view of the whole issue,
I would appreciate any input.

(As soon as I get it all to work, I will make it available.)

Thanks.

db