Re: [9fans] Private Namespaces for Linux

Re: [9fans] Private Namespaces for Linux

[Russ Cox]

> I think you have to write bigger books to compete with the 3kg
> behemoths.  Publishers like wider books because they are more visible
> on bookshelves and at least some of the buying public seem to believe
> that a bigger book is better because `surely in all those pages there
> will be an answer to any question I might have', though that hasn't
> been my experience.  I find that the behemoths are forced to cover all
> topics superficially since they attempt to be encyclopædic by touching
> all topics lightly rather than going into detail on any (or many) of
> them (and admittedly that might require multiple volumes, per The Art
> of Computer Programming).

hget http://metalab.unc.edu/Dave/Dr-Fun/df200002/df20000210.jpg |page -w

Re: [9fans] Private Namespaces for Linux

[Skip Tavakkolian]

Could "illiterate programming" be far behind?

At 10:09 PM 11/26/2001 -0500, Russ Cox wrote:
>> I think you have to write bigger books to compete with the 3kg
>> behemoths.  Publishers like wider books because they are more visible
>> on bookshelves and at least some of the buying public seem to believe
>> that a bigger book is better because `surely in all those pages there
>> will be an answer to any question I might have', though that hasn't
>> been my experience.  I find that the behemoths are forced to cover all
>> topics superficially since they attempt to be encyclopædic by touching
>> all topics lightly rather than going into detail on any (or many) of
>> them (and admittedly that might require multiple volumes, per The Art
>> of Computer Programming).
>
>hget http://metalab.unc.edu/Dave/Dr-Fun/df200002/df20000210.jpg |page -w
>
>

Re: [9fans] Private Namespaces for Linux

[Ralph Corderoy]

Hi Andrew,

> I wasn't meaning to imply that the documents aren't excellent and a
> pleasure to read, but I personally am a book junkie, and it was "The
> Unix Programming Environment" that convinced me, by showing the
> philosophy behind it, that Unix was not just a hard-to-use
> abomination that only a techie could love, but was a productive
> environment for getting work done.

Do you read German?

    http://luna2.informatik.uni-osnabrueck.de/axel/books/
    http://luna2.informatik.uni-osnabrueck.de/axel/books/plan9.gif

    Plan 9
    with H.-P. Bischof, G. Imeyer, B. Khl,
    1999, Hanser, Munich, ISBN 3-446-18881-9.

I'd like to see an English translation of this.

Cheers,


Ralph.

Re: [9fans] Private Namespaces for Linux

[nigel]

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

Or:

TAOCP Vol XIII: "Invent your own algorithms for fun and profit"?


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

From: Skip Tavakkolian <skipt@real.com>
To: 9fans@cse.psu.edu, 9fans@cse.psu.edu
Subject: Re: [9fans] Private Namespaces for Linux
Date: Tue, 27 Nov 2001 00:13:32 -0800
Message-ID: <3.0.5.32.20011127001332.018d8310@mail.real.com>

Could "illiterate programming" be far behind?

At 10:09 PM 11/26/2001 -0500, Russ Cox wrote:
>> I think you have to write bigger books to compete with the 3kg
>> behemoths.  Publishers like wider books because they are more visible
>> on bookshelves and at least some of the buying public seem to believe
>> that a bigger book is better because `surely in all those pages there
>> will be an answer to any question I might have', though that hasn't
>> been my experience.  I find that the behemoths are forced to cover all
>> topics superficially since they attempt to be encyclopædic by touching
>> all topics lightly rather than going into detail on any (or many) of
>> them (and admittedly that might require multiple volumes, per The Art
>> of Computer Programming).
>
>hget http://metalab.unc.edu/Dave/Dr-Fun/df200002/df20000210.jpg |page -w
>
>

Re: [9fans] Private Namespaces for Linux

[nigel]

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

> I was sort of under the impression that the sort of people who would have fun
> with Plan 9 are those who already have more fun with TeX or lout than Word.
> Could be wrong, though.

Hmm, never used TeX in my life. Perhaps I'm not having fun with Plan 9.


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

From: Quinn Dunkan <quinn@chunder.ugcs.caltech.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Private Namespaces for Linux
Date: Mon, 26 Nov 2001 18:22:57 -0800
Message-ID: <20011127022302.233B2781C8@chunder.ugcs.caltech.edu>


> > intellectual inertia
> > satisfaction with the status quo
> > following the crowd
> > listening to the people who shout the loudest
> > fashion
> > no integrated web browser/mail reader/nntp client/html wysiwyg editor
> >
> I hesitate to use the "M" word around here, but from my perspective the
> absence of anything like MS Excel, Word, and Access is a big disincentive.

I was sort of under the impression that the sort of people who would have fun
with Plan 9 are those who already have more fun with TeX or lout than Word.
Could be wrong, though.

> Also maybe the absence of any books doesn't help visibility. Something like
> "The Plan 9 Programming Environment" would be welcome.

As far as programming in C goes, I think plan 9 is actually better off than
unix or windows with their large bookshelves.  From my point of view:

The best kind of documentation is that which doesn't need to be there.  Plan 9
lacks a lot of historical cruft and spiky pit traps that need documentation
under, say, unix.  The documentation that is there is easy to find and
download and read on the screen or print out if desired, or can even be bought
in hard copy.  This is more flexible than a paper book which only has the last
option.  And lastly (and not leastly), the source is there, and easy to find,
and relatively free of ifdefs and cross-platform special cases and accumulated
toejam.

The situation is less good if C happens to not be your favorite language, but
people who use "minority" languages usually face the same sort of "write it
yourself, then" issues that people who use minority OSes face.

Re: [9fans] Private Namespaces for Linux

[David Gordon Hogan]

> I also thought there might be an outside chance that one or two of the
> people one sees in bookstores struggling with the 3kg Linux and Java
> behemoths ...

Perhaps this would be a useful book to consider including:

     http://www.slackbastard.net/~polaris/orabanms.gif

<choke!>

Re: [9fans] Private Namespaces for Linux

[Boyd Roberts]

> You're probably right in general, but there are at least some
> schizophrenics who appreciate the economy and elegance of Plan 9, but who
> would sooner chew broken glass than use TeX or troff.

I'd crawl across broken glass to use troff.  Just don't get me started on
TeX.

Re: [9fans] Private Namespaces for Linux

[geoff]

I think you have to write bigger books to compete with the 3kg
behemoths.  Publishers like wider books because they are more visible
on bookshelves and at least some of the buying public seem to believe
that a bigger book is better because `surely in all those pages there
will be an answer to any question I might have', though that hasn't
been my experience.  I find that the behemoths are forced to cover all
topics superficially since they attempt to be encyclopædic by touching
all topics lightly rather than going into detail on any (or many) of
them (and admittedly that might require multiple volumes, per The Art
of Computer Programming).

Re: [9fans] Private Namespaces for Linux

[Andrew Simmons]

>
>I was sort of under the impression that the sort of people who would have fun
>with Plan 9 are those who already have more fun with TeX or lout than Word.
>Could be wrong, though.
>
You're probably right in general, but there are at least some
schizophrenics who appreciate the economy and elegance of Plan 9, but who
would sooner chew broken glass than use TeX or troff.

Re: [9fans] Private Namespaces for Linux

[Andrew Simmons]

>
>No, it's the behemoths you get inertia problems with.
>
I knew someone was going to say that as soon as I hit "Send".

Re: [9fans] Private Namespaces for Linux

[Boyd Roberts]

> I also thought there might be an outside chance that one or two of the
> people one sees in bookstores struggling with the 3kg Linux and Java
> behemoths might get inspired to try something different if they caught
> sight of a smaller volume describing a better way. Probably too much
> inertia against it, though.

No, it's the behemoths you get inertia problems with.

Re: [9fans] Private Namespaces for Linux

[Quinn Dunkan]

> > intellectual inertia
> > satisfaction with the status quo
> > following the crowd
> > listening to the people who shout the loudest
> > fashion
> > no integrated web browser/mail reader/nntp client/html wysiwyg editor
> >
> I hesitate to use the "M" word around here, but from my perspective the
> absence of anything like MS Excel, Word, and Access is a big disincentive.

I was sort of under the impression that the sort of people who would have fun
with Plan 9 are those who already have more fun with TeX or lout than Word.
Could be wrong, though.

> Also maybe the absence of any books doesn't help visibility. Something like
> "The Plan 9 Programming Environment" would be welcome.

As far as programming in C goes, I think plan 9 is actually better off than
unix or windows with their large bookshelves.  From my point of view:

The best kind of documentation is that which doesn't need to be there.  Plan 9
lacks a lot of historical cruft and spiky pit traps that need documentation
under, say, unix.  The documentation that is there is easy to find and
download and read on the screen or print out if desired, or can even be bought
in hard copy.  This is more flexible than a paper book which only has the last
option.  And lastly (and not leastly), the source is there, and easy to find,
and relatively free of ifdefs and cross-platform special cases and accumulated
toejam.

The situation is less good if C happens to not be your favorite language, but
people who use "minority" languages usually face the same sort of "write it
yourself, then" issues that people who use minority OSes face.

Re: [9fans] Private Namespaces for Linux

[Andrew Simmons]

>
>Actually I think the documents are quite excellent.

I wasn't meaning to imply that the documents aren't excellent and a
pleasure to read, but I personally am a book junkie, and it was "The Unix
Programming Environment" that convinced me, by showing the philosophy
behind it, that Unix was not just a hard-to-use abomination that only a
techie could love, but was a productive environment for getting work done.

I also thought there might be an outside chance that one or two of the
people one sees in bookstores struggling with the 3kg Linux and Java
behemoths might get inspired to try something different if they caught
sight of a smaller volume describing a better way. Probably too much
inertia against it, though.

Re: [9fans] Private Namespaces for Linux

[Ronald G Minnich]

On Tue, 27 Nov 2001, Andrew Simmons wrote:

> Also maybe the absence of any books doesn't help visibility. Something like
> "The Plan 9 Programming Environment" would be welcome.

Actually I think the documents are quite excellent. I used them to build
my 9p and other code, and once I got to see source last summer, I was
pretty surprised to find out I actually got a fair amount of stuff right
(and some stuff wrong, to be honest).

The weirdest thing was dumping the name space and seeing ... pretty much
the same stuff I dump for a name space.

So, yes, there is no "One Book" but I found the writeups to be incredibly
useful.

ron

Re: [9fans] Private Namespaces for Linux

[Andrew Simmons]

> intellectual inertia
> satisfaction with the status quo
> following the crowd
> listening to the people who shout the loudest
> fashion
> no integrated web browser/mail reader/nntp client/html wysiwyg editor
>
I hesitate to use the "M" word around here, but from my perspective the
absence of anything like MS Excel, Word, and Access is a big disincentive.
Also maybe the absence of any books doesn't help visibility. Something like
"The Plan 9 Programming Environment" would be welcome.

Re: [9fans] Private Namespaces for Linux

[erik quanstrom]

>I'm just saddened that people are shoe-horning isolated ideas from
>Plan 9 into old, outdated systems, rather than comprehending the
>full elegance of Plan 9 as a complete system, and lending their
>support to it.
>
>It's very much like the New Testament parable about
>patching old wineskins...

then you also know the parable of the sower and the seed?

i'm glad that linux is adopting (some) plan9 ideas. if there's
enough of a taste of (and compatability with) plan9 in linux,
i think a lot more people will see that plan9 is pretty cool.

it's better than the alternative, linux could become more like
mach.

erik

Re: [9fans] Private Namespaces for Linux

[Dan Cross]

In article <Pine.LNX.4.33.0111260704450.16611-100000@snaresland.acl.lanl.gov> you write:
>No, it needs to be chucked. But as we all keep saying, "Installed Base".
>You can't ignore that. If you put a really solid Linux emulation layer in
>there (do you really want to support all 220 system calls?) you might have
>a chance. Except it's so much slower in certain areas ... that's a
>problem.
>
>Did you want to take the job of porting Emacs to Plan 9?

What about VSTa?  It seems like it had the right ideas, but never fledged.
I think that the installed base/inertia/glamour thing has a lot more to do
with it than anything else.

	- Dan C.

Re: [9fans] Private Namespaces for Linux

[Ronald G Minnich]

On Mon, 26 Nov 2001, Matt wrote:
> intellectual inertia
> satisfaction with the status quo
> following the crowd
> listening to the people who shout the loudest
> fashion
> no integrated web browser/mail reader/nntp client/html wysiwyg editor


That and the several tens of Gigabytes of in-use source code makes it
tricky. Hey, be sure to let me know when PGI Fortran runs on Plan 9, ok?

ron

Re: [9fans] Private Namespaces for Linux

[Ronald G Minnich]

On Mon, 26 Nov 2001, David Gordon Hogan wrote:

> I'm just saddened that people are shoe-horning isolated ideas from
> Plan 9 into old, outdated systems, rather than comprehending the
> full elegance of Plan 9 as a complete system, and lending their
> support to it.

Life is like that sometimes. I tried very hard to lend my support 10 years
ago. I tried like crazy to get Plan 9 at the Supercomputing Research
Center. Since the SRC was at the University of Maryland Science and
Technology Center, at one point I tried sending letter head with "U.
Maryland S&T Center" to see if Bell Labs would sort of ignore the fact
that I wasn't *really* at the U. Maryland. No good. I spent two years
sending letters to lawyers. I finally decided "looks like they don't want
people to use it after all".

Later, at Sarnoff, ca. 1995, I tried again. That was about the time of the
"$350 for personal use, $200K (to start) for business use" fiasco.
Remember that? It's like saying "take a risk, throw away all your support
software, and oh by the way if it works you owe us a lot of money".
Brilliant.  Somehow, monopoly phone companies never really did get the
idea of marketing.

I have friends who were in ATT from ca. 1972 to the late 80s, and they
have told me there was a substantial contingent of clueless managers in
ATT who felt that releasing *Unix* to the outside world was a huge
mistake, and that while they lost the battle with Unix, they did not
intend to lose it with Plan 9. That would sure explain a lot.

The whole Plan 9 story (from the outside) looks like a long series of
attempts by ATT/Lucent to kill it. Think of ATT/Lucent as Wily Coyote and
Plan 9 as Roadrunner.

So there's a reason I started adding this stuff to legacy OSes.

I really think had ATT done the right thing in 1991, we'd all be using
Plan 9 now. I am convinced of that. As it is, they ran around suing
college students over the rights to 20-year-old files which were available
in the open literature. If anything convinced people to steer clear of
ATT-encumbered code, that was probably a big thing.

> It's very much like the New Testament parable about
> patching old wineskins...

In industry this type of retrofit (Plan 9 ideas to Linux) is usually
called "Operation Silk Purse".

> Really, Linux needs to be rewritten from the ground up,
> along with all them GNU tools.  Or we could all just use
> Plan 9...

No, it needs to be chucked. But as we all keep saying, "Installed Base".
You can't ignore that. If you put a really solid Linux emulation layer in
there (do you really want to support all 220 system calls?) you might have
a chance. Except it's so much slower in certain areas ... that's a
problem.

Did you want to take the job of porting Emacs to Plan 9?

ron

Re: [9fans] Private Namespaces for Linux

[Matt]

On Monday 26 November 2001 10:00, you wrote:
> dhog@plan9.bell-labs.com (David Gordon Hogan) writes:
> > I'm just saddened that people are shoe-horning isolated ideas from
> > Plan 9 into old, outdated systems, rather than comprehending the
> > full elegance of Plan 9 as a complete system, and lending their
> > support to it.
>
> What do you think the reasons are those people have for not such
> comprehension and lending of support?

intellectual inertia
satisfaction with the status quo
following the crowd
listening to the people who shout the loudest
fashion
no integrated web browser/mail reader/nntp client/html wysiwyg editor

Re: [9fans] Private Namespaces for Linux

[Thomas Bushnell, BSG]

dhog@plan9.bell-labs.com (David Gordon Hogan) writes:

> I'm just saddened that people are shoe-horning isolated ideas from
> Plan 9 into old, outdated systems, rather than comprehending the
> full elegance of Plan 9 as a complete system, and lending their
> support to it.

What do you think the reasons are those people have for not such
comprehension and lending of support?

Re: [9fans] Private Namespaces for Linux

[David Gordon Hogan]

> > So your solution is to gradually evolve Linux until it becomes
> > Plan 9, rather than just using Plan 9?
>
> The oddity here is that David's email contains the subtext that it's
> *bad* for Plan 9 ideas to be adopted elsewhere!

I'm just saddened that people are shoe-horning isolated ideas from
Plan 9 into old, outdated systems, rather than comprehending the
full elegance of Plan 9 as a complete system, and lending their
support to it.

It's very much like the New Testament parable about
patching old wineskins...

Really, Linux needs to be rewritten from the ground up,
along with all them GNU tools.  Or we could all just use
Plan 9...

Re: [9fans] Private Namespaces for Linux

[david presotto]

As someone else pointed out, one of the reasons for IL was to have something
useful before we had a reasonable TCP floating around.  TCP is considerably
more code even before you start adding congestion control.  It made getting
a number of small special purpose systems up and running quicker to use
someting
like IL.  I couldn't have imagined getting TCP into early versions of Ken's
file server.

However, now that we have a mature TCP, I don't see a lot of reason for IL.
When we provile the code for both IL and TCP, the bulk of the time is still
in checksum and memmove and handling the interrupt.   Most of the code in
TCP doesn't fire very often.

Re: [9fans] Private Namespaces for Linux

[George Michaelson]

Its worth tracking some of the TCP implementors lists/groups in IETF like
the PILC stuff. A bit of debate is going on right now about how some apps
work better if the initial send is full-on, to speed up convergeance onto the
full window size. Given all the prominence slow-start has as a good thing for
wider Internet scaling, it seems a bit contrairy, but if the protocol exchange
in question is going to be over in 2-3 sends anyway, if you don't start full
bore, you never get there (so to speak)

That might be true for the RPC like nature of 9's use of the network.

cheers
	-George
-
George Michaelson       |  APNIC
Email: ggm@apnic.net    |  PO Box 2131 Milton QLD 4064
Phone: +61 7 3367 0490  |  Australia
  Fax: +61 7 3367 0482  |  http://www.apnic.net

Re: [9fans] Private Namespaces for Linux

[Thomas Bushnell, BSG]

dhog@plan9.bell-labs.com (David Gordon Hogan) writes:

> So your solution is to gradually evolve Linux until it becomes
> Plan 9, rather than just using Plan 9?

The oddity here is that David's email contains the subtext that it's
*bad* for Plan 9 ideas to be adopted elsewhere!

Re: [9fans] Private Namespaces for Linux

[rob pike]

> Most of the user-level file servers that we had were converted in an
> hour or so.

That is, an hour or so *each*.  It's not quite trivial.

-rob

Re: [9fans] Private Namespaces for Linux

[rob pike]

> how backwards compatible will 9p2000 be?

Semantically, it's quite similar.  The syntax of the messages is quite
different in spots, but that's mostly hidden by the library, or would
be except the library changed too.  Nothing difficult, though; in fact
I find the new directory handling interface (for clients, not servers)
nicer than the old.

Most of the user-level file servers that we had were converted in an
hour or so.  I think I converted both rio and acme in one brief
session.  A few more subtle ones, and our main stand-alone file
server, took much more work for various reasons.  Ftpfs was nasty
because the way the new walk message works is hard to simulate using
the FTP protocol.  Except for such oddballs, I would say the work of
conversion seems proportionate to the complexity of the server itself.

Of course, people less familiar with the conversion process will need
more time to do the work.

So don't worry about the new protocol when you write your server;
conversion won't be a big deal.

-rob

Re: [9fans] Private Namespaces for Linux

[Matt]

On Wednesday 21 November 2001 23:02, you wrote:
> > Maybe the TCP overhead isn't as bad in practice as originally feared.
>
> The point about message delimiters is more relevant to why IL is less
> relevant to us today.  The 9P2000 protocol is easy to parse and the new
> code handles assembly early on, so delimiters are no longer necessary
> or even helpful.
>
> -rob

how backwards compatible will 9p2000 be?

I'm just getting to a point where I want to implement my first fileserver and
although no time will be wasted doing it in the [not yet] old way how
different will 9p2000 implementation be?

Re: [9fans] Private Namespaces for Linux

[rob pike]

> Maybe the TCP overhead isn't as bad in practice as originally feared.

The point about message delimiters is more relevant to why IL is less
relevant to us today.  The 9P2000 protocol is easy to parse and the new
code handles assembly early on, so delimiters are no longer necessary
or even helpful.

-rob

Re: [9fans] Private Namespaces for Linux

[Andrew Simmons]

>To ask a rude question then, what was the original need or rationale for
>inventing IL?
>

The original rationale in http://plan9.bell-labs.com/sys/doc/il/il.pdf
reads as follows:

None of the standard IP protocols [RFC791] is suitable for transmission
of 9P messages over an Ethernet or the Internet. TCP [RFC793] has a high
overhead and
does not preserve delimiters. UDP [RFC768], while cheap and preserving message
delimiters, does not provide reliable sequenced delivery. When we were
implementing
IP, TCP, and UDP in our system we tried to choose a protocol suitable for
carrying 9P.
The properties we desired were:
¡ Reliable datagram service
¡ In-sequence delivery
¡ Internetworking using IP
¡ Low complexity, high performance
¡ Adaptive timeouts
No standard protocol met our needs so we designed a new one, called IL
(Internet Link).

Maybe the TCP overhead isn't as bad in practice as originally feared.

Re: [9fans] Private Namespaces for Linux

[Ronald G Minnich]

On Wednesday 21 November 2001 10:51, Skip Tavakkolian wrote:
> Did the $200 equation factor in your time to develop the Linux version?
>
> >- In 1995/6 when I started this project, Plan 9 was just simply not
> >available, unless you wanted to plunk down $200K+, which my company could
> >not afford. But I needed these ideas for work I was doing.

It's a bigger problem than that. If I use Linux + private name spaces, I have
something I can use commercially. If I cut over to Plan 9, I lose all the
application base.

Plus, DARPA paid for my time :-)

ron

Re: [9fans] Private Namespaces for Linux

[Skip Tavakkolian]

To ask a rude question then, what was the original need or rationale for
inventing IL?

At 09:52 AM 11/21/2001 -0500, presotto@closedmind.org wrote:
>server = PentiumII/Xeon 400
>client = PentiumPro 199
>network = 100 mbs ether
>
>test =
>	import {tcp|il}!olive / /tmp
>	cd /tmp/386/bin; cat * > /dev/null
>
>the remote fs protocol is 9P2000
>
>I did a few runs to warm up the cache on the
>server and 7 runs each for IL and TCP interleaved.
>The timings came out just about the same for
>Il and TCP, 29.17 and 29.38 secs respectively.
>The difference was well within the error bars.
>
>Received: from mail.cse.psu.edu ([130.203.4.6]) by plan9; Tue Nov 20
18:41:49 EST 2001
>Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.20.6])
>	by mail.cse.psu.edu (CSE Mail Server) with ESMTP
>	id 04B4519A8A; Tue, 20 Nov 2001 18:41:38 -0500 (EST)
>Delivered-To: 9fans@cse.psu.edu
>Received: from math.psu.edu (leibniz.math.psu.edu [146.186.130.2])
>	by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 39CBC19A47
>	for <9fans@cse.psu.edu>; Tue, 20 Nov 2001 18:40:48 -0500 (EST)
>Received: from augusta.math.psu.edu (augusta.math.psu.edu [146.186.132.2])
>	by math.psu.edu (8.9.3/8.9.3) with ESMTP id SAA21220
>	for <9fans@cse.psu.edu>; Tue, 20 Nov 2001 18:40:47 -0500 (EST)
>From: Dan Cross <cross@math.psu.edu>
>Received: (from cross@localhost)
>	by augusta.math.psu.edu (8.9.3+Sun/8.9.3) id SAA18771;
>	Tue, 20 Nov 2001 18:40:47 -0500 (EST)
>Message-Id: <200111202340.SAA18771@augusta.math.psu.edu>
>To: 9fans@cse.psu.edu
>Subject: Re: [9fans] Private Namespaces for Linux
>Newsgroups: comp.os.plan9
>In-Reply-To: <20011120220809.8D66B199E4@mail.cse.psu.edu>
>Organization: Mememememememmeme
>Cc:
>Sender: 9fans-admin@cse.psu.edu
>Errors-To: 9fans-admin@cse.psu.edu
>X-BeenThere: 9fans@cse.psu.edu
>X-Mailman-Version: 2.0.7
>Precedence: bulk
>Reply-To: 9fans@cse.psu.edu
>List-Help: <mailto:9fans-request@cse.psu.edu?subject=help>
>List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu>
>List-Archive: <http://lists.cse.psu.edu/archives/9fans/>
>Date: Tue, 20 Nov 2001 18:40:47 -0500 (EST)
>
>In article <20011120220809.8D66B199E4@mail.cse.psu.edu> you write:
>>OK, OK, here's why IL is deprecated:
>>
>>1.  It doesn't cope well with long networks (it hasn't
>>had the chance to be tuned to the same degree as TCP).
>>
>>2.  It's a headache to maintain.
>>
>>3.  The new protocol (9P2000) doesn't depend on record
>>boundaries being preserved; there is basically no dependence
>>on IL in the new system other than the current fileserver
>>implementation, which is about to be overhauled (RSN!).
>
>Yes, but isn't il a lot more efficient on the wire than TCP,
>particularly over mostly reliable local area networks?  TCP has a lot
>of baggage to deal with high loss, high latency, networks with moderate
>bandwidth at the expense of higher bandwidth, lower latency, low loss
>networks; in other words, it doesn't cope well with short networks.  :-)
>
>	- Dan C.
>

Re: [9fans] Private Namespaces for Linux

[Dan Cross]

In article <20011121145219.5E53D199E7@mail.cse.psu.edu> you write:
>server = PentiumII/Xeon 400
>client = PentiumPro 199
>network = 100 mbs ether
>
>test =
>	import {tcp|il}!olive / /tmp
>	cd /tmp/386/bin; cat * > /dev/null
>
>the remote fs protocol is 9P2000
>
>I did a few runs to warm up the cache on the
>server and 7 runs each for IL and TCP interleaved.
>The timings came out just about the same for
>Il and TCP, 29.17 and 29.38 secs respectively.
>The difference was well within the error bars.

Wow....  Okay, that answers my question.

	- Dan C.

Re: [9fans] Private Namespaces for Linux

[erik quanstrom]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 149 bytes --]

let them eat cake!

☺

----------
So your solution is to gradually evolve Linux until it becomes
Plan 9, rather than just using Plan 9?

Re: [9fans] Private Namespaces for Linux

[Skip Tavakkolian]

Did the $200 equation factor in your time to develop the Linux version?

>- In 1995/6 when I started this project, Plan 9 was just simply not
>available, unless you wanted to plunk down $200K+, which my company could
>not afford. But I needed these ideas for work I was doing.

Re: [9fans] Private Namespaces for Linux

[Thomas Bushnell, BSG]

dhog@plan9.bell-labs.com (David Gordon Hogan) writes:

> > > Disallowing su, passwd, sendmail, etc etc isn't really a solution...
> >
> > Sure, but there are ways to handle that.  And until it's done we need
> > restricted mount.
>
> So your solution is to gradually evolve Linux until it becomes
> Plan 9, rather than just using Plan 9?

Sure.  The strategy of gradually evolving Linux to become Plan 9 is at
least feasible for most Linux users; "just using Plan 9" is impossible
for a great many of them.

Re: [9fans] Private Namespaces for Linux

[forsyth]

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

and gotchas have been added, eg Nagle small-packet `optimisation'


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

To: 9fans@cse.psu.edu
Subject: Re: [9fans] Private Namespaces for Linux
Date: Wed, 21 Nov 2001 16:05:13 +0100
Message-ID: <3BFBC2A9.A35221DD@strakt.com>

> 1.  It doesn't cope well with long networks (it hasn't
> had the chance to be tuned to the same degree as TCP).

Yes, TCP has had a lot of work done to it over the years
to get the gotchas out of it;  silly window syndrome, slow
start, etc ...

Re: [9fans] Private Namespaces for Linux

[Boyd Roberts]

> 1.  It doesn't cope well with long networks (it hasn't
> had the chance to be tuned to the same degree as TCP).

Yes, TCP has had a lot of work done to it over the years
to get the gotchas out of it;  silly window syndrome, slow
start, etc ...

Re: [9fans] Private Namespaces for Linux

[presotto]

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

server = PentiumII/Xeon 400
client = PentiumPro 199
network = 100 mbs ether

test =
	import {tcp|il}!olive / /tmp
	cd /tmp/386/bin; cat * > /dev/null

the remote fs protocol is 9P2000

I did a few runs to warm up the cache on the
server and 7 runs each for IL and TCP interleaved.
The timings came out just about the same for
Il and TCP, 29.17 and 29.38 secs respectively.
The difference was well within the error bars.


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

From: Dan Cross <cross@math.psu.edu>
To: 9fans@cse.psu.edu
Cc: 
Subject: Re: [9fans] Private Namespaces for Linux
Date: Tue, 20 Nov 2001 18:40:47 -0500 (EST)
Message-ID: <200111202340.SAA18771@augusta.math.psu.edu>

In article <20011120220809.8D66B199E4@mail.cse.psu.edu> you write:
>OK, OK, here's why IL is deprecated:
>
>1.  It doesn't cope well with long networks (it hasn't
>had the chance to be tuned to the same degree as TCP).
>
>2.  It's a headache to maintain.
>
>3.  The new protocol (9P2000) doesn't depend on record
>boundaries being preserved; there is basically no dependence
>on IL in the new system other than the current fileserver
>implementation, which is about to be overhauled (RSN!).

Yes, but isn't il a lot more efficient on the wire than TCP,
particularly over mostly reliable local area networks?  TCP has a lot
of baggage to deal with high loss, high latency, networks with moderate
bandwidth at the expense of higher bandwidth, lower latency, low loss
networks; in other words, it doesn't cope well with short networks.  :-)

	- Dan C.

Re: [9fans] Private Namespaces for Linux

[Taj Khattra]

On Tue, Nov 20, 2001 at 01:57:15PM -0700, Ronald G Minnich wrote:
> On Tuesday 20 November 2001 13:49, David Gordon Hogan wrote:
> > > I hope this code is useful to somebody. The 9p protocol was a real breath
> > > of fresh air after years of hacking NFS and SunRPC.
> >
> > Damn straight!
> >
> > You should implement IL for those platforms while you're at it....
>
> Funny you should mention that. I'm looking at it.

i thought pace willisson had already done this for the second edition

-taj

Re: [9fans] Private Namespaces for Linux

[Ronald G Minnich]

On Wed, 21 Nov 2001 okamoto@granite.cias.osakafu-u.ac.jp wrote:

> Why viro and Ronald are trying to implement Plan 9 features to
> Unices, which Plan 9 designers decided to abandon because it's
> no use to adopt old ideas to make new Operating system.

well, all things being equal, I think you are right. All things are not
equal:

- In 1995/6 when I started this project, Plan 9 was just simply not
available, unless you wanted to plunk down $200K+, which my company could
not afford. But I needed these ideas for work I was doing.

- From the beginning, ATT/Lucent did a really thorough job of screwing
Plan 9 distro up (seems to be a tradition with ATT and software). I doubt
they could have done more damage to it had they tried. I had some concern
at the time that these great ideas would die if ATT/Lucent succeeded in
their efforts to kill plan 9. An open source implementation seemed like a
good idea.

- For my purposes plan 9 is not (yet) a usable OS. Does PGI Fortran run on
Plan 9? No. Matlab? No. IDL? No. and so on. Installed software base is an
issue.

- It is not really hard to put private name spaces into a legacy OS. Just
because Plan 9 has excellent ideas, and Linux does not have those ideas,
is no reason not to put some of those excellent ideas into Linux,
especially if it is not that hard to do. If I have to have Linux, I might
as well try to make it more usable.

So that's why i did it.

ron

Re: [9fans] Private Namespaces for Linux

[Eric Grosse]

> How difficult would it be to have linux
> (or anything with PAM) use plan9 for
> authentication?

We're changing the Plan 9 security structure somewhat.  My hope is that the new
code will indeed help with PAM, but that is still to be investigated.

Re: [9fans] Private Namespaces for Linux

[okamoto]

Sorry to interrupt into technical discussion.

Why viro and Ronald are trying to implement Plan 9 features to
Unices, which Plan 9 designers decided to abandon because it's
no use to adopt old ideas to make new Operating system.   I'm not
an expert of OS, so, I may be doing something "funny" here...

Kenji

Re: [9fans] Private Namespaces for Linux

[David Gordon Hogan]

> I'm sure that 9fans must find supporting all the
> new fancy hardware out there a little tedious.

It'd be less tedious if more people out there were
doing it.

(Provided they don't do such an awful job of writing
a driver as much of the Linux crowd!).

Re: [9fans] Private Namespaces for Linux

[Matthew Hannigan]

I don't think that that is such a bad way to
go, since linux does such a good job in hardware
support.

I'm sure that 9fans must find supporting all the
new fancy hardware out there a little tedious.

-Matt


David Gordon Hogan wrote:
>
> > > Disallowing su, passwd, sendmail, etc etc isn't really a solution...
> >
> > Sure, but there are ways to handle that.  And until it's done we need
> > restricted mount.
>
> So your solution is to gradually evolve Linux until it becomes
> Plan 9, rather than just using Plan 9?

Re: [9fans] Private Namespaces for Linux

[Matthew Hannigan]

How difficult would it be to have linux
(or anything with PAM) use plan9 for
authentication?

-Matt

Re: [9fans] Private Namespaces for Linux

[forsyth]

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

>>1.  It doesn't cope well with long networks (it hasn't
>>had the chance to be tuned to the same degree as TCP).

there are of course two ways of interpreting that last part...


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

To: 9fans@cse.psu.edu
Subject: Re: [9fans] Private Namespaces for Linux
Date: Tue, 20 Nov 2001 17:08:05 -0500
Message-ID: <20011120220809.8D66B199E4@mail.cse.psu.edu>

OK, OK, here's why IL is deprecated:

1.  It doesn't cope well with long networks (it hasn't
had the chance to be tuned to the same degree as TCP).

2.  It's a headache to maintain.

3.  The new protocol (9P2000) doesn't depend on record
boundaries being preserved; there is basically no dependence
on IL in the new system other than the current fileserver
implementation, which is about to be overhauled (RSN!).

Re: [9fans] Private Namespaces for Linux

[Alexander Viro]

On Tue, 20 Nov 2001, David Gordon Hogan wrote:

> > > Disallowing su, passwd, sendmail, etc etc isn't really a solution...
> >
> > Sure, but there are ways to handle that.  And until it's done we need
> > restricted mount.
>
> So your solution is to gradually evolve Linux until it becomes
> Plan 9, rather than just using Plan 9?

Umm...  I'd say that there is a bit more to Plan 9 than userland that
doesn't need setuid.  Or to Linux, for that matter.

What's more, reducing the need in setuid is generally considered a Good
Thing(tm) regardless of the OS...

Re: [9fans] Private Namespaces for Linux

[Dan Cross]

In article <20011120220809.8D66B199E4@mail.cse.psu.edu> you write:
>OK, OK, here's why IL is deprecated:
>
>1.  It doesn't cope well with long networks (it hasn't
>had the chance to be tuned to the same degree as TCP).
>
>2.  It's a headache to maintain.
>
>3.  The new protocol (9P2000) doesn't depend on record
>boundaries being preserved; there is basically no dependence
>on IL in the new system other than the current fileserver
>implementation, which is about to be overhauled (RSN!).

Yes, but isn't il a lot more efficient on the wire than TCP,
particularly over mostly reliable local area networks?  TCP has a lot
of baggage to deal with high loss, high latency, networks with moderate
bandwidth at the expense of higher bandwidth, lower latency, low loss
networks; in other words, it doesn't cope well with short networks.  :-)

	- Dan C.

Re: [9fans] Private Namespaces for Linux

[David Gordon Hogan]

> > Disallowing su, passwd, sendmail, etc etc isn't really a solution...
>
> Sure, but there are ways to handle that.  And until it's done we need
> restricted mount.

So your solution is to gradually evolve Linux until it becomes
Plan 9, rather than just using Plan 9?

Re: [9fans] Private Namespaces for Linux

[Alexander Viro]

On Tue, 20 Nov 2001, David Gordon Hogan wrote:

> > set-uid is stupid. So I don't allow it.
>
> Plan 9 doesn't even have set-uid.
>
> But I think you misunderstand.  There are two problems to
> be addressed: (1) rogue fileservers serving up set-uid files
> (not a problem for 9P, but relevant to Unix-based protocols
> like NFS...);

Nosuid.

> (2) attacks like the following:
>
> 	$ bind /tmp/passwd /etc/passwd
> 	$ su
>
> Disallowing su, passwd, sendmail, etc etc isn't really a solution...

Sure, but there are ways to handle that.  And until it's done we need
restricted mount.

Re: [9fans] Private Namespaces for Linux

[Alexander Viro]

On Tue, 20 Nov 2001, David Gordon Hogan wrote:

> Just out of curiousity, how does the Linux ``namespaces''
> implementation handle the many juicy attacks possible
> against set-uid programs?  Do set-uid programs get
> thrown into a default namespace?

Keep in mind that currently mount(2) is still very seriously restricted -
there will be a lot of work on userland before we will be able to lift
these restrictions.  Ideally we should be able to get rid of setuid -
it is doable, but will take quite a while.  For a lot of uses even
root-only mount(2) combined with per-process namespaces (new flag to
clone(2) equivalent to RF_NAMEG and usual semantics on exit(2)) gives
much more than possible with traditional Unices.

Another thing being, nosuid is per-mountpoint.  I.e. you can have
the same fs mounted with nosuid in some namespaces and without - in
other.

It will certainly take a lot of work to clean the userland up - there
will be a long transition.  OTOH, these cleanups are needed anyway.
That's actually one of the reasons why 9pfs is so interesting - it
would simplify quite a few of these issues.

Re: [9fans] Private Namespaces for Linux

[Ronald G Minnich]

On Tuesday 20 November 2001 15:54, David Gordon Hogan wrote:
> Plan 9 doesn't even have set-uid.

Yeah I know. Those are the guys who made me realize set-uid was stupid, back
when I had no gray hairs.

> But I think you misunderstand.  There are two problems to
> be addressed: (1) rogue fileservers serving up set-uid files
> (not a problem for 9P, but relevant to Unix-based protocols
> like NFS...);

I'm probably missing something. Here is my understanding of how this all
goes. Bear in mind that the last time I thought about this at all was a while
back. I have not tested it on the latest Linux distributions.

I clear setuid bits in the client-side VFS. So you can't get a setuid to even
happen via the kernel exec, even if the bit could move over 9P, which it
can't.

For the libc hack, you are limited to what you can do from user mode, so I am
pretty sure that route is closed too, due to precautions taken in ld.so.
Recall that the libc hack simply redirects stuff like open() to a library,
which translates the ops to 9P and sends the request to a server. This really
depends on ld.so honoring LD_PRELOAD. It doesn't for setuid programs (at
least on systems I have used).

> (2) attacks like the following:
>
> 	$ bind /tmp/passwd /etc/passwd
> 	$ su

1) Kernel-mode VFS: The su will fail as it has no setuid bits.

2) User-mode libc hack: the behavior on systems I use is  that LD_PRELOAD has
    no effect
    on programs with setuid set, and stuff like LD_LIBRARY_PATH is ignored.
    That may have changed -- it should not have, since that was a very early
    sunos exploit ca. 1988 when they first did shared libraries (shared
     libraries are not my favorite thing either). You set LD_LIBRARY_PATH to
         somewhere bad, run su, voila! you're root.
    (I could look but probably these env variables are cleared in the kernel.
     I can't remember which OS I saw this on, but it gets done in some of
  them)

> Disallowing su, passwd, sendmail, etc etc isn't really a solution...

Well, Plan 9 doesn't need stuff like that. Linux shouldn't either, but sadly
it does. That's why I expect Unix-like OSes like Linux to die soon, but then
again I've been expecting that every year for a long time ... however
security is more in the front of people's minds lately. And the things I've
seen done to LInux for security are so ugly, when I see them, I ask people:
have you looked at Plan 9. (two answers: 1) what's that (95%); 2) but nobody
uses that, so you need our gross hacks (5%). )

Say, does anybody remember those same two responses for Unix?

Anyway for this project I decided to ditch priveleged ports and set-uid.
They're just a bad thing.

ron
p.s. check out the dynsys page at uwisc.edu for their discussion of handling
lingering processes under Condor that can commandeer other Condor processes.
They have a cute fix, but under Plan 9 it is totally unnecessary.

Re: [9fans] Private Namespaces for Linux

[Alexander Viro]

On Tue, 20 Nov 2001, Ronald G Minnich wrote:

> Hmm, now what. Given the pace of change in 2.4 kernels, I can perhaps be
> forgiven for wondering how solid all this will be.

-S<foo> is for 2.4.<foo>.  I'll upload variants against 2.4.14 and
2.4.15-pre7 tonight.  Keep in mind that large parts of that stuff went
into the tree (pretty much all 2.4 changes in fs/super.c and fs/namespace.c
are results of the gradual merge with that).

Apologies for long delay with updates - there was a lot of other work lately.

> Sorry to pollute this list with a non-plan-9 discussion, however, so I won't
> respond to further flames unless they're private. Some messages are not worth
> responding to in public.

???  I definitely had no intention to flame you and I've seen no reasons
whatsoever to start doing that.

However, flames or not, it is, indeed, off-topic here.  If you want to
continue the thread in private - you are certainly welcome.  I'm very
interested in 9pfs and more than willing to discuss the VFS changes that
had happened during 2.3/2.4 and ones that are going to happen in 2.5.<early>.

								Al

Re: [9fans] Private Namespaces for Linux

[David Gordon Hogan]

> set-uid is stupid. So I don't allow it.

Plan 9 doesn't even have set-uid.

But I think you misunderstand.  There are two problems to
be addressed: (1) rogue fileservers serving up set-uid files
(not a problem for 9P, but relevant to Unix-based protocols
like NFS...); (2) attacks like the following:

	$ bind /tmp/passwd /etc/passwd
	$ su

Disallowing su, passwd, sendmail, etc etc isn't really a solution...

Re: [9fans] Private Namespaces for Linux

[Ronald G Minnich]

On Tuesday 20 November 2001 15:40, David Gordon Hogan wrote:
> Just out of curiousity, how does the Linux ``namespaces''
> implementation handle the many juicy attacks possible
> against set-uid programs?  Do set-uid programs get
> thrown into a default namespace?

set-uid is stupid. So I don't allow it.

ron

Re: [9fans] Private Namespaces for Linux

[David Gordon Hogan]

Just out of curiousity, how does the Linux ``namespaces''
implementation handle the many juicy attacks possible
against set-uid programs?  Do set-uid programs get
thrown into a default namespace?

Re: [9fans] Private Namespaces for Linux

[Ronald G Minnich]

On Tuesday 20 November 2001 14:48, Ronald G Minnich wrote:
>
> > To start with, namespaces had been available on 2.4 since at least
> > March.  See patches on ftp.math.psu.edu/pub/viro/ - namespaces-* is that
> > + related VFS cleanups.  Currently most of that is merged into the main
> > tree. Remaining stuff will go in when I'll somewhat clean the backlog on
> > other things.  And it's a real thing - it isn't limited to #M
> > combinations, any fs can be used.

So for those of you, like me, who try to follow this up:

The patches:
cftp /pub/viro > ls *name*
U4-rename-S5                           namespaces-a-S8-pre2
namespaces-S2.gz@                      namespaces-a-S8-pre3
namespaces-a-S10-pre2                  namespaces-a-S8-pre4
namespaces-a-S10-pre9                  namespaces-b-S3-pre8.gz
namespaces-a-S11-pre5.gz               namespaces-b-S4-pre6.gz
namespaces-a-S2.gz                     namespaces-c-S4-pre6.gz
namespaces-a-S4.gz                     namespaces-c-S5
namespaces-a-S6-pre2                   namespaces-c-S5-pre6.gz
namespaces-a-S6-pre5                   namespaces-d-S2.gz
namespaces-a-S7-pre3                   namespaces-d-S4-pre6.gz
ncftp /pub/viro >

Hmm, now what. Given the pace of change in 2.4 kernels, I can perhaps be
forgiven for wondering how solid all this will be.

Anyway, once it's really in I'll be happy to give it a shot. Although some
folks I know who are using it aren't quite sure it fits the description of
"private name spaces"

Also, Linux-specific only. My stuff does do the libc hack on several other
OSes, including freebsd.

Just FYI.

Oh, forgot to mention: the libc interface to my stuff also supports exporting
a name space and importing it into another process -- e.g. a child. You
really need that for fork(). But I think this will work in combination with
Erik Hendrik's bproc stuff, so you can get the equivalent of cpu on a
Scyld-based cluster. I have tested exporting name spaces to other processes
on other machines, and it works fine.

Oh, one other thing: Peter Braam and I did an alternate way of doing private
name spaces a few years ago on Linux, see the pnsdev at www.sourceforge.net.

Sorry to pollute this list with a non-plan-9 discussion, however, so I won't
respond to further flames unless they're private. Some messages are not worth
responding to in public.

ron

Re: [9fans] Private Namespaces for Linux

[presotto]

To expand, IL causes problems with a number of ISP's.
It doesn't do its own fragmentation, it depends on IP.
Therefore when doing large reads and writes, it generates
packet trains, pieces of which are often lost due to
congestion.  The only option is to retransmit the IL
packet and hence the packet chain, which in turn has
a reasonable probablility of a loss.

To fix it, we'ld have to introduce fragmentation/reassembly to
IL.  That may or may not be enough in which case we may have to
worry about additional congestion control.  (I think we could
get away without cc because of the inherent RPC nature of 9p
over IL).  However, we figured that at that point we're getting
dangerously close to TCP anyways so why bother; we've got too
many other things to do and our TCP implementation is getting
to be industrial strength due to Dong Lin's efforts.

There's also the general problem that IL gets filtered out
at a lot of firewalls because noone knows about it: I have
to use TCP to get out of Avaya because I can't get anyone
to turn on IL at the corporate edge.

Re: [9fans] Private Namespaces for Linux

[David Gordon Hogan]

OK, OK, here's why IL is deprecated:

1.  It doesn't cope well with long networks (it hasn't
had the chance to be tuned to the same degree as TCP).

2.  It's a headache to maintain.

3.  The new protocol (9P2000) doesn't depend on record
boundaries being preserved; there is basically no dependence
on IL in the new system other than the current fileserver
implementation, which is about to be overhauled (RSN!).

Re: [9fans] Private Namespaces for Linux

[erik quanstrom]

>> > You should implement IL for those platforms while you're at it....
>>
>> Funny you should mention that. I'm looking at it.
>
>Actually, you might as well not bother.  Word around the lab is that
>IL is deprecated...

okay, i'll bite. why? please explain.

saying it this way makes it sound as if it died a political
death in some smokey back room.

Re: [9fans] Private Namespaces for Linux

[Ronald G Minnich]

On Tuesday 20 November 2001 14:24, David Gordon Hogan wrote:

> Actually, you might as well not bother.  Word around the lab is that
> IL is deprecated...


yikes. It seemed like a better deal than TCP, did the lab conclude otherwise.


ron

Re: [9fans] Private Namespaces for Linux

[Ronald G Minnich]

On Tuesday 20 November 2001 14:08, Alexander Viro wrote:

> > I put private namespaces in too. I.e. I put in system call to support
> > Plan-9 style session, attach, mount, and then have the VFS read/write
> > etc. go to a VFS with plan9-style operations, communicating 9p to a
> > server (I only have two: a memfs and a ufs). Union mounts work in the
> > plan 9 style. I also have a library which does the "hijack function calls
> > to libc" so that you have it from user mode on other OSes.
>
> Ugh.

Ugh? what's ugh? You can create a local name in your private name space that
connects to a remote place, with the remote server being accessed via 9p, and
the remote server being pretty much any 9p server. Which may or may not be
dishing out stuff from a file system or some other place (the
server-of-services list I mentioned in the paper, or other things). I don't
get your point.

> To start with, namespaces had been available on 2.4 since at least
> March.  See patches on ftp.math.psu.edu/pub/viro/ - namespaces-* is that
> + related VFS cleanups.  Currently most of that is merged into the main
> tree. Remaining stuff will go in when I'll somewhat clean the backlog on
> other things.  And it's a real thing - it isn't limited to #M combinations,
> any fs can be used.

Well, which kernel version. I've been playing Kernel-of-the-week here, and
there's still stuff that won't compile if you turn it on. I did try (but
failed) to use your patches. I'll try again, it looked good if I could get it
to work.

Also bear in mind I wrote this code in 1995-6 or so (so long ago I forget the
exact dates), when I still had to argue with people about why private name
spaces are better than 'chroot'. My first port was to 2.0, not 2.4. This
stuff had lain unused for 2.5 years until the Dobbs article appeared. I did
rebuild it and the user-mode stuff all works, which makes my day. Also I had
*zero* access to Plan 9 when I did it -- which is why I did it!

I'll look at your stuff again, if it's better than mine (probably) I'll use
it. I'm more concerned with having something to use, so if your stuff will do
what I want, I'm fine with that.


> BTW, could you use the standard meanings of terms?  Filesystem is
> filesystem, whether it's disk-based or completely syntetic.

I think I used the term 'server', which I prefer. I thought that was the Plan
9 usage anyway. I have found the term "filesystem" is a bad term, since so
many people interpret it so many different ways -- but I slip up and use it
anyway...

> VFS is more or
> less an equivalent of chan.c and sysfile.c - what you had described looks
> rather like devmnt.c with some strange additions.

Well, things get a bit mixed up when we discuss this stuff. There is not an
exact correspondance between bits of Linux and bits of Plan 9. But no, it is
not devmnt.c. I'm not quite sure why you think this is like the devmnt stuff.

ron

Re: [9fans] Private Namespaces for Linux

[David Gordon Hogan]

> > You should implement IL for those platforms while you're at it....
>
> Funny you should mention that. I'm looking at it.

Actually, you might as well not bother.  Word around the lab is that
IL is deprecated...

Re: [9fans] Private Namespaces for Linux

[Alexander Viro]

On Tue, 20 Nov 2001, Ronald G Minnich wrote:

> On Tuesday 20 November 2001 10:28, Thomas Bushnell, BSG wrote:
>
> > Is the subject incorrect though?  It's cool to have a port of the Plan
> > 9 FS protocol to Linux (et al), but it seems to me that would be a
> > different task from private namespaces.
>
> I put private namespaces in too. I.e. I put in system call to support Plan-9
> style session, attach, mount, and then have the VFS read/write etc. go to a
> VFS with plan9-style operations, communicating 9p to a server (I only have
> two: a memfs and a ufs). Union mounts work in the plan 9 style. I also have a
> library which does the "hijack function calls to libc" so that you have it
> from user mode on other OSes.

Ugh.  To start with, namespaces had been available on 2.4 since at least
March.  See patches on ftp.math.psu.edu/pub/viro/ - namespaces-* is that
+ related VFS cleanups.  Currently most of that is merged into the main tree.
Remaining stuff will go in when I'll somewhat clean the backlog on other
things.  And it's a real thing - it isn't limited to #M combinations, any
fs can be used.

9pfs is definitely very welcome, though.

BTW, could you use the standard meanings of terms?  Filesystem is filesystem,
whether it's disk-based or completely syntetic.  VFS is more or less an
equivalent of chan.c and sysfile.c - what you had described looks rather like
devmnt.c with some strange additions.

Re: [9fans] Private Namespaces for Linux

[Ronald G Minnich]

On Tuesday 20 November 2001 13:49, David Gordon Hogan wrote:
> > I hope this code is useful to somebody. The 9p protocol was a real breath
> > of fresh air after years of hacking NFS and SunRPC.
>
> Damn straight!
>
> You should implement IL for those platforms while you're at it....

Funny you should mention that. I'm looking at it.

ron

Re: [9fans] Private Namespaces for Linux

[presotto]

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

There's always dong's IL and 9P implementations in FreeBSD.  They
might be helpful to people.

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

From: David Gordon Hogan <dhog@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Private Namespaces for Linux
Date: Tue, 20 Nov 2001 15:49:44 -0500
Message-ID: <20011120204948.16A5B19A3F@mail.cse.psu.edu>

> I hope this code is useful to somebody. The 9p protocol was a real breath
> of fresh air after years of hacking NFS and SunRPC.

Damn straight!

You should implement IL for those platforms while you're at it....

Re: [9fans] Private Namespaces for Linux

[David Gordon Hogan]

> I hope this code is useful to somebody. The 9p protocol was a real breath
> of fresh air after years of hacking NFS and SunRPC.

Damn straight!

You should implement IL for those platforms while you're at it....

Re: [9fans] Private Namespaces for Linux

[Ronald G Minnich]

On Tuesday 20 November 2001 10:28, Thomas Bushnell, BSG wrote:

> Is the subject incorrect though?  It's cool to have a port of the Plan
> 9 FS protocol to Linux (et al), but it seems to me that would be a
> different task from private namespaces.

I put private namespaces in too. I.e. I put in system call to support Plan-9
style session, attach, mount, and then have the VFS read/write etc. go to a
VFS with plan9-style operations, communicating 9p to a server (I only have
two: a memfs and a ufs). Union mounts work in the plan 9 style. I also have a
library which does the "hijack function calls to libc" so that you have it
from user mode on other OSes.

Test was to have a login with no mounted file systems available. All you got
was a shell called KISS, which let you do the session/attach/mount commands
and build up your name space. The acid test was, of course, running Emacs. It
worked.

So, yes, this is the correct subject.

ron

Re: [9fans] Private Namespaces for Linux

[Thomas Bushnell, BSG]

matt@proweb.co.uk (Matt) writes:

> http://www.ddj.com/documents/s=1782/ddj0112a/0112a.htm
>
> "Working from publicly available documents, I've built an implementation of
> the Plan 9 filesystem protocol and tested its user-mode components on
> FreeBSD, Solaris, SunOS, and Linux. I have also written a kernel-mode virtual
> filesystem (VFS) that runs on Linux."

Is the subject incorrect though?  It's cool to have a port of the Plan
9 FS protocol to Linux (et al), but it seems to me that would be a
different task from private namespaces.

Re: [9fans] Private Namespaces for Linux

[forsyth]

	I hope this code is useful to somebody. The 9p protocol was a real breath
	of fresh air after years of hacking NFS and SunRPC.

without a doubt.

Re: [9fans] Private Namespaces for Linux

[Ronald G Minnich]

On Mon, 19 Nov 2001, Matt wrote:

> Dr Dobbs has an interesting article
>
> Private Namespaces for Linux
> Uses for distributed and cluster computing
>
> By Ronald G. Minnich
>
> http://www.ddj.com/documents/s=1782/ddj0112a/0112a.htm
>
> "Working from publicly available documents, I've built an implementation of
> the Plan 9 filesystem protocol and tested its user-mode components on
> FreeBSD, Solaris, SunOS, and Linux. I have also written a kernel-mode virtual
> filesystem (VFS) that runs on Linux."
>

I did the best I could absent the real plan 9 code :-)

source is now at http://www.acl.lanl.gov/~rminnich

I am trying to put this on the sourceforge with a much longer paper (from
which the Dobbs article is derived) that is much more detail-filled.

I hope this code is useful to somebody. The 9p protocol was a real breath
of fresh air after years of hacking NFS and SunRPC.

ron

[9fans] Private Namespaces for Linux

[Matt]

Dr Dobbs has an interesting article

Private Namespaces for Linux
Uses for distributed and cluster computing

By Ronald G. Minnich

http://www.ddj.com/documents/s=1782/ddj0112a/0112a.htm

"Working from publicly available documents, I've built an implementation of
the Plan 9 filesystem protocol and tested its user-mode components on
FreeBSD, Solaris, SunOS, and Linux. I have also written a kernel-mode virtual
filesystem (VFS) that runs on Linux."