From: Fco.J.Ballesteros <nemo@plan9.escet.urjc.es>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] A proposal regarding # in bind
Date: Mon, 24 Feb 2003 20:29:24 +0100 [thread overview]
Message-ID: <445a2e694b4a666d6a7c9b24d0a5ee06@plan9.escet.urjc.es> (raw)
In-Reply-To: <3203694a344338d2aae59b328b9fe67a@vitanuova.com>
An alternative to having a special system call
could be for RFCNAMEG to mean `a namespace with just
a reasonable set of kernel devices mounted under /ur'.
There'd be no bootstrap problem (well, it would be hidden inside the code
for RFCNAMEG).
This alternative would lead to:
1. the problem of using just some of the devices and not
all of them.
2. the problem of `which one is the reasonable set' (eg. we probably
dont want #| there for each RFCNAMEG).
If the implementation of RFCNAMEG becomes just a bunch of attach calls
to the set of `reasonable' # names, and we permit unmount on, say, /ur/console
then I'd say that 1 is not a problem.
Regarding 2, I don't have an answer (other than keeping #| or changing
its semantics---eg. creating pipes by cloning and not by attaching).
next prev parent reply other threads:[~2003-02-24 19:29 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-24 19:04 rog
2003-02-24 19:04 ` rob pike, esq.
2003-02-24 19:53 ` Jack Johnson
2003-02-25 4:37 ` Martin C.Atkins
2003-02-25 11:02 ` chris
2003-02-25 14:01 ` Martin C.Atkins
2003-02-25 14:11 ` Russ Cox
2003-02-25 14:17 ` Martin C.Atkins
2003-02-25 14:34 ` Russ Cox
2003-02-25 14:36 ` Russ Cox
2003-02-25 14:52 ` Ronald G. Minnich
2003-02-25 19:57 ` northern snowfall
2003-02-25 16:49 ` Dan Cross
2003-02-26 5:12 ` Martin C.Atkins
2003-02-24 19:29 ` Fco.J.Ballesteros [this message]
2003-02-24 22:34 ` George Michaelson
2003-02-24 23:32 ` Bruce Ellis
2003-02-25 5:02 ` Martin C.Atkins
2003-02-25 11:19 ` chris
2003-02-25 14:06 ` Martin C.Atkins
2003-02-26 0:04 ` Bruce Ellis
2003-02-26 6:06 ` Skip Tavakkolian
2003-02-25 5:00 ` Martin C.Atkins
2003-02-25 9:05 ` [9fans] lpdaemon probs Conor Williams
2003-02-25 10:07 ` Geoff Collyer
2003-02-25 10:33 ` Conor Williams
2003-02-25 23:50 ` Geoff Collyer
2003-02-27 9:59 ` [9fans] lpdaemon probs (fix) Conor Williams
2003-02-27 20:57 ` Geoff Collyer
-- strict thread matches above, loose matches on Subject: below --
2003-02-26 23:46 [9fans] A proposal regarding # in bind a
2003-02-26 22:44 a
2003-02-26 23:02 ` Russ Cox
2003-02-26 21:26 John Stalker
2003-02-27 8:29 ` Fco.J.Ballesteros
2003-02-26 14:56 rog
2003-02-26 15:02 ` Russ Cox
2003-02-26 6:21 okamoto
2003-02-26 13:32 ` Digby Tarvin
2003-02-26 13:58 ` Russ Cox
2003-02-26 14:14 ` Russ Cox
2003-02-26 14:33 ` Boyd Roberts
2003-02-26 15:28 ` Ronald G. Minnich
2003-02-24 19:25 Joel Salomon
2003-02-25 4:33 ` Martin C.Atkins
2003-02-24 15:19 Martin C.Atkins
2003-02-24 15:28 ` Boyd Roberts
2003-02-24 18:36 ` rob pike, esq.
2003-02-25 4:57 ` Martin C.Atkins
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=445a2e694b4a666d6a7c9b24d0a5ee06@plan9.escet.urjc.es \
--to=nemo@plan9.escet.urjc.es \
--cc=9fans@cse.psu.edu \
/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).