9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: G. David Butler gdb@dbSystems.com
Subject: Permissions on names served by the kernel
Date: Wed, 27 Dec 1995 00:04:18 -0500	[thread overview]
Message-ID: <19951227050418.28c6q3c36UqdlaKjQ0Us6FFrL0N8N9kQ6pCa7cEyyA4@z> (raw)

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






             reply	other threads:[~1995-12-27  5:04 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1995-12-27  5:04 G.David [this message]
  -- strict thread matches above, loose matches on Subject: below --
1995-12-27 17:29 G.David
1995-12-27 17:24 philw
1995-12-20 19:41 philw
1995-12-20 19:06 G.David

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=19951227050418.28c6q3c36UqdlaKjQ0Us6FFrL0N8N9kQ6pCa7cEyyA4@z \
    --to=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).