[9fans] Van Jacobsen's network stack restructure

[9fans] Van Jacobsen's network stack restructure

[Christopher Nielsen]

anyone seen this?

http://www.lemis.com/grog/Documentation/vj/

i don't know if his methods have any application to Plan 9, since the
Plan 9 IP stack doesn't seem to have the lineage of the linux and bsd
stacks. i am not intimate with the IP stack code, but it might bear a
lookover.

it at least has me curious enough to go digging around through the code. :-)

--
Christopher Nielsen
"They who can give up essential liberty for temporary
safety, deserve neither liberty nor safety." --Benjamin Franklin

Re: [9fans] Van Jacobsen's network stack restructure

[ems]

Do the PDFs on that site seem malformed? Or is it just a corrupted
download?
On Tue, 2006-01-31 at 20:28 -0800, Christopher Nielsen wrote:
> anyone seen this?
> 
> http://www.lemis.com/grog/Documentation/vj/
> 
> i don't know if his methods have any application to Plan 9, since the
> Plan 9 IP stack doesn't seem to have the lineage of the linux and bsd
> stacks. i am not intimate with the IP stack code, but it might bear a
> lookover.
> 
> it at least has me curious enough to go digging around through the code. :-)
> 
> --
> Christopher Nielsen
> "They who can give up essential liberty for temporary
> safety, deserve neither liberty nor safety." --Benjamin Franklin

Re: [9fans] Van Jacobsen's network stack restructure

[Christopher Nielsen]

they were fine for me.

using debian/x86, acrobat7

On 1/31/06, ems <oat@iinet.net.au> wrote:
> Do the PDFs on that site seem malformed? Or is it just a corrupted
> download?
> On Tue, 2006-01-31 at 20:28 -0800, Christopher Nielsen wrote:
> > anyone seen this?
> >
> > http://www.lemis.com/grog/Documentation/vj/
> >
> > i don't know if his methods have any application to Plan 9, since the
> > Plan 9 IP stack doesn't seem to have the lineage of the linux and bsd
> > stacks. i am not intimate with the IP stack code, but it might bear a
> > lookover.
> >
> > it at least has me curious enough to go digging around through the code. :-)
> >
> > --
> > Christopher Nielsen
> > "They who can give up essential liberty for temporary
> > safety, deserve neither liberty nor safety." --Benjamin Franklin
>
>


--
Christopher Nielsen
"They who can give up essential liberty for temporary
safety, deserve neither liberty nor safety." --Benjamin Franklin

Re: [9fans] Van Jacobsen's network stack restructure

[ems]

Thanks, I downloaded it again, still malformed for me.

I am also using debian/x86. My reader is Evince. Going to file a bug.

Thanks.

On Tue, 2006-01-31 at 22:00 -0800, Christopher Nielsen wrote:
> they were fine for me.
> 
> using debian/x86, acrobat7
> 
> On 1/31/06, ems <oat@iinet.net.au> wrote:
> > Do the PDFs on that site seem malformed? Or is it just a corrupted
> > download?
> > On Tue, 2006-01-31 at 20:28 -0800, Christopher Nielsen wrote:
> > > anyone seen this?
> > >
> > > http://www.lemis.com/grog/Documentation/vj/
> > >
> > > i don't know if his methods have any application to Plan 9, since the
> > > Plan 9 IP stack doesn't seem to have the lineage of the linux and bsd
> > > stacks. i am not intimate with the IP stack code, but it might bear a
> > > lookover.
> > >
> > > it at least has me curious enough to go digging around through the code. :-)
> > >
> > > --
> > > Christopher Nielsen
> > > "They who can give up essential liberty for temporary
> > > safety, deserve neither liberty nor safety." --Benjamin Franklin
> >
> >
> 
> 
> --
> Christopher Nielsen
> "They who can give up essential liberty for temporary
> safety, deserve neither liberty nor safety." --Benjamin Franklin

Re: [9fans] Van Jacobsen's network stack restructure

[Federico G. Benavento]

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

oat, 

the pdf works fine with page(1)

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

From: ems <oat@iinet.net.au>
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] Van Jacobsen's network stack restructure
Date: Wed, 01 Feb 2006 16:57:31 +1100
Message-ID: <1138773451.17224.13.camel@heater.intranet.ebr>

Do the PDFs on that site seem malformed? Or is it just a corrupted
download?
On Tue, 2006-01-31 at 20:28 -0800, Christopher Nielsen wrote:
> anyone seen this?
> 
> http://www.lemis.com/grog/Documentation/vj/
> 
> i don't know if his methods have any application to Plan 9, since the
> Plan 9 IP stack doesn't seem to have the lineage of the linux and bsd
> stacks. i am not intimate with the IP stack code, but it might bear a
> lookover.
> 
> it at least has me curious enough to go digging around through the code. :-)
> 
> --
> Christopher Nielsen
> "They who can give up essential liberty for temporary
> safety, deserve neither liberty nor safety." --Benjamin Franklin

Re: [9fans] Van Jacobsen's network stack restructure

[uriel]

> anyone seen this?
> 
> http://www.lemis.com/grog/Documentation/vj/
Yes quite interesting, and here is a nice writeup: 
http://vger.kernel.org/~davem/cgi-bin/blog.cgi/2006/01/27
 
> i don't know if his methods have any application to Plan 9, since the
> Plan 9 IP stack doesn't seem to have the lineage of the linux and bsd
> stacks. i am not intimate with the IP stack code, but it might bear a
> lookover.
>From the very little I know about our IP stack(which comes from reading Nemo's
excellent commentary on the 3rd edition kernel source), we might be not too
far from a design similar to what is described there, but I might be completely
wrong.

And even if it's not, /net makes it easy to put the IP stack in user space without
having to change a single line of application code. Ah, the more I deal with
Plan 9, the more I love it :)

Maybe we should try to convince those lunix people to replace sockets with
something like /net? ;)

uriel

> 
> it at least has me curious enough to go digging around through the code. :-)
> 

Re: [9fans] Van Jacobsen's network stack restructure

[Skip Tavakkolian]

> Maybe we should try to convince those lunix people to replace sockets with
> something like /net? ;)

i would highly recommend gene therapy over transplantation.

Re: [9fans] Van Jacobsen's network stack restructure

[Charles Forsyth]

> i don't know if his methods have any application to Plan 9, since the
> Plan 9 IP stack doesn't seem to have the lineage of the linux and bsd
> stacks. i am not intimate with the IP stack code, but it might bear a
> lookover.

i think there might be a nice irony: i understood that a variant of plan 9 (brazil)
did put the networking code in /ip outside the kernel,
but it returned inside to improve performance.
of course, the structure was a little different from VJ's suggestion.

it seems to me that one could make many of the improvements inside the kernel
without putting the code in libraries (although there's an implication that there might
be a choice of implementations for different applications).
one disadvantage of the library approach in the unix environment is that
you're once again back having to know which `access method' to use,
to pass the file descriptor or handle to the right library.
i might easily have misunderstood something though.

Re: [9fans] Van Jacobsen's network stack restructure

[Bakul Shah]

> one disadvantage of the library approach in the unix environment is that
> you're once again back having to know which `access method' to use,
> to pass the file descriptor or handle to the right library.
> i might easily have misunderstood something though.

They already have the file descriptor (i.e. socket descr) in
order to get at the data.  All they have to do is to mmap
some memory and have the network controller copy incoming tcp
packets for this connection directly into this memory.  By
using this memory as a circular buffer one can avoid all
locking (memory in the range [read ptr .. write ptr) is owned
by the app, [write ptr .. read ptr) is owned by the driver).
The driver will have to checksum the pkt and be able to
map seq. # to a memory address within the buffer but one can
do all the grotty protocol processing in the user code.  A
similar buffer can be used for outgoing data.  I bet they do
something along these lines.

Hasn't this idea been used in various forms over the years?

Re: [9fans] Van Jacobsen's network stack restructure

[C H Forsyth]

>> one disadvantage of the library approach in the unix environment is that
>> you're once again back having to know which `access method' to use,
>> to pass the file descriptor or handle to the right library.
>> i might easily have misunderstood something though.

> [reasonable explanation deleted]
> I bet they do something along these lines.

yes, i supposed it could be something along those lines but i didn't make my point clear.
if it is along those lines, it breaks something that even sockets didn't break.
at the moment, i get a file descriptor that i can pass to anything that does read and write.
now i've got something that i can only mmap, and even the mmap refers to a
non-trivial data structure shared with the kernel, and the recipient of the file descriptor
must invoke special calls in a special library (ie, the `access method').
i suppose you could call it TCAM

Re: [9fans] Van Jacobsen's network stack restructure

[Bakul Shah]

> >> one disadvantage of the library approach in the unix environment is that
> >> you're once again back having to know which `access method' to use,
> >> to pass the file descriptor or handle to the right library.
> >> i might easily have misunderstood something though.
> 
> > [reasonable explanation deleted]
> > I bet they do something along these lines.
> 
> yes, i supposed it could be something along those lines but i didn't make my 
> point clear.
> if it is along those lines, it breaks something that even sockets didn't brea
> k.
> at the moment, i get a file descriptor that i can pass to anything that does 
> read and write.
> now i've got something that i can only mmap, and even the mmap refers to a
> non-trivial data structure shared with the kernel, and the recipient of the f
> ile descriptor
> must invoke special calls in a special library (ie, the `access method').
> i suppose you could call it TCAM

Once you have mmap (and most versions of Unix do these days)
you have already bought into the associated complexity.  If
you pass a file descriptor with an associated mmap to a
process, what happens is determined by mmap flags used when
the mapping was created.  So all I am saying is that there
is nothing "special" about it.  It is no more "broken".  And
at least this is a useful extension (in that it can make the
kernel simpler without losing performance if they take out
any compatibility crap).  If you exclusively used mmap for
files, even more stuff can potentially be taken out of the
kernel -- just pass the received data map directly to the
file server process.

Re: [9fans] Van Jacobsen's network stack restructure

[David Leimbach]

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

On 2/2/06, Bakul Shah <bakul+plan9@bitblocks.com> wrote:
>
> > >> one disadvantage of the library approach in the unix environment is
> that
> > >> you're once again back having to know which `access method' to use,
> > >> to pass the file descriptor or handle to the right library.
> > >> i might easily have misunderstood something though.
> >
> > > [reasonable explanation deleted]
> > > I bet they do something along these lines.
> >
> > yes, i supposed it could be something along those lines but i didn't
> make my
> > point clear.
> > if it is along those lines, it breaks something that even sockets didn't
> brea
> > k.
> > at the moment, i get a file descriptor that i can pass to anything that
> does
> > read and write.
> > now i've got something that i can only mmap, and even the mmap refers to
> a
> > non-trivial data structure shared with the kernel, and the recipient of
> the f
> > ile descriptor
> > must invoke special calls in a special library (ie, the `access
> method').
> > i suppose you could call it TCAM
>
> Once you have mmap (and most versions of Unix do these days)
> you have already bought into the associated complexity.  If
> you pass a file descriptor with an associated mmap to a
> process, what happens is determined by mmap flags used when
> the mapping was created.  So all I am saying is that there
> is nothing "special" about it.  It is no more "broken".  And
> at least this is a useful extension (in that it can make the
> kernel simpler without losing performance if they take out
> any compatibility crap).  If you exclusively used mmap for
> files, even more stuff can potentially be taken out of the
> kernel -- just pass the received data map directly to the
> file server process.
>

And with 64bit Virtual Memory why not mmap everything? [except for the
thrashing on my poor hard disk and lack of terrabytes of physical memory :)]

I jokingly have been saying this to only close personal friends for a while.

Why can't I mmap a remote process's memory?  Some embedded systems [used
to?] let me do this and pass messages with memcpy :).

Throw off the shackles of "read" and "write" calls.... use mmap instead :)

*chuckle*

[-- Attachment #2: Type: text/html, Size: 2712 bytes --]

Re: [9fans] Van Jacobsen's network stack restructure

[Ronald G Minnich]

David Leimbach wrote:

> Why can't I mmap a remote process's memory?  Some embedded systems [used 
> to?] let me do this and pass messages with memcpy :).

http://mbgokhale.org/rminnich, look at the zounds stuff, user-mode 
library that let you do the moral equivalent. You could, as a server, 
attach a chunk of your memory to a socket endpoint, and you could, as a 
client, do same. Voila, your memory is my memory. Then I added multicast 
sockets. For the server side, you could optionally fork off a child that 
served the memory segment out.

OK, ok, I am sure it is ugly to even mention such a thing on this list, 
but I claim the excuse of utility. Once I added multicast, this library 
let me move a 16 MByte voxel cube to every node in a 128-node cluster in 
about the time it took to move it to 1. It greatly shortened the startup 
time for a || rendering  app.

There's actually a few people out there still using this library, I hear 
from them from time to time. I have not worked on it in 10 years.

FreeBSD and Linux were supported.


ron

Re: [9fans] Van Jacobsen's network stack restructure

[quanstro]

c'mon. linux has consistently gone the other way on this issue.
linux doesn't even have a device node for network interfaces.

i don't know anything about the reasoning for this. efficiency?
support for a static /dev? i don't know.


- erik

On Wed Feb  1 11:50:33 CST 2006, uriel@cat-v.org wrote:
> > anyone seen this?
> > 
> > http://www.lemis.com/grog/Documentation/vj/
> Yes quite interesting, and here is a nice writeup: 
> http://vger.kernel.org/~davem/cgi-bin/blog.cgi/2006/01/27
>  
> > i don't know if his methods have any application to Plan 9, since the
> > Plan 9 IP stack doesn't seem to have the lineage of the linux and bsd
> > stacks. i am not intimate with the IP stack code, but it might bear a
> > lookover.
> >From the very little I know about our IP stack(which comes from reading Nemo's
> excellent commentary on the 3rd edition kernel source), we might be not too
> far from a design similar to what is described there, but I might be completely
> wrong.
> 
> And even if it's not, /net makes it easy to put the IP stack in user space without
> having to change a single line of application code. Ah, the more I deal with
> Plan 9, the more I love it :)
> 
> Maybe we should try to convince those lunix people to replace sockets with
> something like /net? ;)

Re: [9fans] Van Jacobsen's network stack restructure

[David Leimbach]

On 2/1/06, quanstro@quanstro.net <quanstro@quanstro.net> wrote:
> c'mon. linux has consistently gone the other way on this issue.
> linux doesn't even have a device node for network interfaces.

Except maybe for tap interfaces.  I've had to mess with source that
was written for linux so it worked with FreeBSD's paths in their
devfs.

>
> i don't know anything about the reasoning for this. efficiency?
> support for a static /dev? i don't know.

Probably because they don't have a single devfs they can agree on?

>
>
> - erik
>
> On Wed Feb  1 11:50:33 CST 2006, uriel@cat-v.org wrote:
> > > anyone seen this?
> > >
> > > http://www.lemis.com/grog/Documentation/vj/
> > Yes quite interesting, and here is a nice writeup:
> > http://vger.kernel.org/~davem/cgi-bin/blog.cgi/2006/01/27
> >
> > > i don't know if his methods have any application to Plan 9, since the
> > > Plan 9 IP stack doesn't seem to have the lineage of the linux and bsd
> > > stacks. i am not intimate with the IP stack code, but it might bear a
> > > lookover.
> > >From the very little I know about our IP stack(which comes from reading Nemo's
> > excellent commentary on the 3rd edition kernel source), we might be not too
> > far from a design similar to what is described there, but I might be completely
> > wrong.
> >
> > And even if it's not, /net makes it easy to put the IP stack in user space without
> > having to change a single line of application code. Ah, the more I deal with
> > Plan 9, the more I love it :)
> >
> > Maybe we should try to convince those lunix people to replace sockets with
> > something like /net? ;)
>

Re: [9fans] Van Jacobsen's network stack restructure

[David Leimbach]

On 2/1/06, quanstro@quanstro.net <quanstro@quanstro.net> wrote:
> c'mon. linux has consistently gone the other way on this issue.
> linux doesn't even have a device node for network interfaces.
>
> i don't know anything about the reasoning for this. efficiency?
> support for a static /dev? i don't know.
>

The bash shell supports /dev/tcp.... kind of evil but you can make
connections and send strings via file redirection with it.

Dave

>
> - erik
>
> On Wed Feb  1 11:50:33 CST 2006, uriel@cat-v.org wrote:
> > > anyone seen this?
> > >
> > > http://www.lemis.com/grog/Documentation/vj/
> > Yes quite interesting, and here is a nice writeup:
> > http://vger.kernel.org/~davem/cgi-bin/blog.cgi/2006/01/27
> >
> > > i don't know if his methods have any application to Plan 9, since the
> > > Plan 9 IP stack doesn't seem to have the lineage of the linux and bsd
> > > stacks. i am not intimate with the IP stack code, but it might bear a
> > > lookover.
> > >From the very little I know about our IP stack(which comes from reading Nemo's
> > excellent commentary on the 3rd edition kernel source), we might be not too
> > far from a design similar to what is described there, but I might be completely
> > wrong.
> >
> > And even if it's not, /net makes it easy to put the IP stack in user space without
> > having to change a single line of application code. Ah, the more I deal with
> > Plan 9, the more I love it :)
> >
> > Maybe we should try to convince those lunix people to replace sockets with
> > something like /net? ;)
>

Re: [9fans] Van Jacobsen's network stack restructure

[Ronald G Minnich]

David Leimbach wrote:

> The bash shell supports /dev/tcp.... kind of evil but you can make
> connections and send strings via file redirection with it.


so, on the 'how broken is that' scale, where does this one go?

the scale, btw, goes from 1 to 11

ron

Re: [9fans] Van Jacobsen's network stack restructure

[Christopher Nielsen]

On 2/1/06, Ronald G Minnich <rminnich@lanl.gov> wrote:
> David Leimbach wrote:
>
> > The bash shell supports /dev/tcp.... kind of evil but you can make
> > connections and send strings via file redirection with it.
>
>
> so, on the 'how broken is that' scale, where does this one go?
>
> the scale, btw, goes from 1 to 11
>
> ron

"this one goes to 11!"

--
Christopher Nielsen
"They who can give up essential liberty for temporary
safety, deserve neither liberty nor safety." --Benjamin Franklin

Re: [9fans] Van Jacobsen's network stack restructure

[uriel]

> David Leimbach wrote:
> 
>> The bash shell supports /dev/tcp.... kind of evil but you can make
>> connections and send strings via file redirection with it.
> 
> 
> so, on the 'how broken is that' scale, where does this one go?
> 
> the scale, btw, goes from 1 to 11
Around 16.  

Gawk also has this "feature", wont be long before someone adds
it to cat(1)... 

"do one thing, and do it well" has become
"do everything, everywhere, poorly"

I have been wondering lately why don't the FSF replace the whole Hurd
with bash, it even has emacs(nee libreadline) built in!

All features built into a single program, and then use some sort of
virtualization to provide isolation...  and the software industry has
gone full circle once more.

Some times I wonder if any progress is possible, or for every step forward
we take, we will grow an extra leg that takes us back to square zero.

uriel

Re: [9fans] Van Jacobsen's network stack restructure

[Charles Forsyth]

> "do everything, everywhere, poorly"

in XML

Re: [9fans] Van Jacobsen's network stack restructure

[ems]

This would be Good for a marketing campaign. ;)
On Thu, 2006-02-02 at 10:35 +0000, Charles Forsyth wrote:
> > "do everything, everywhere, poorly"
> 
> in XML

Re: [9fans] Van Jacobsen's network stack restructure

["Nils O. Selåsdal"]

ems wrote:
> This would be Good for a marketing campaign. ;)
> On Thu, 2006-02-02 at 10:35 +0000, Charles Forsyth wrote:
>>> "do everything, everywhere, poorly"
>> in XML
This is, after all, the secret vision of Jabber.
Exhibit A:
http://www.jabber.org/jeps/jeplist.shtml

Re: [9fans] Van Jacobsen's network stack restructure

[Ronald G Minnich]

Charles Forsyth wrote:
>>"do everything, everywhere, poorly"
> 
> 
> in XML
> 

You laugh. I just got beat up on the xen mailing list because I could 
not agree that using XML-RPC was a good idea.

"but there are python bindings for it".

ron

Re: [9fans] Van Jacobsen's network stack restructure

[erik quanstrom]

xml-rpc for python. wow a buzzword-compliance rating of 0.75.

excellent.

- erik

Ronald G Minnich <rminnich@lanl.gov> writes

| 
| Charles Forsyth wrote:
| >>"do everything, everywhere, poorly"
| > 
| > 
| > in XML
| > 
| 
| You laugh. I just got beat up on the xen mailing list because I could 
| not agree that using XML-RPC was a good idea.
| 
| "but there are python bindings for it".
| 
| ron

Re: [9fans] Van Jacobsen's network stack restructure

[Christopher Nielsen]

On 2/2/06, Ronald G Minnich <rminnich@lanl.gov> wrote:
> Charles Forsyth wrote:
> >>"do everything, everywhere, poorly"
> >
> >
> > in XML
> >
>
> You laugh. I just got beat up on the xen mailing list because I could
> not agree that using XML-RPC was a good idea.
>
> "but there are python bindings for it".
>
> ron

one of the startups i worked for a while back was a
linux+apache+java+xml shop. in fact, a lot of the developers of the
apache java apps worked there (many of them are now at google). many
of them were of the mind that you could solve all the worlds problems
with java and xml.

so many people seem to think XML-RPC is the answer to everything.

--
Christopher Nielsen
"They who can give up essential liberty for temporary
safety, deserve neither liberty nor safety." --Benjamin Franklin

Re: [9fans] Van Jacobsen's network stack restructure

[jmk]

On Thu Feb  2 03:24:33 EST 2006, uriel@cat-v.org wrote:
> > David Leimbach wrote:
> > 
> >> The bash shell supports /dev/tcp.... kind of evil but you can make
> >> connections and send strings via file redirection with it.
> > 
> > 
> > so, on the 'how broken is that' scale, where does this one go?
> > 
> > the scale, btw, goes from 1 to 11
> Around 16.  
> ...

Why don't you just make ten louder and make ten be the top...

Re: [9fans] Van Jacobsen's network stack restructure

[Brantley Coile]

But, this is 11!

> On Thu Feb  2 03:24:33 EST 2006, uriel@cat-v.org wrote:
>> > David Leimbach wrote:
>> > 
>> >> The bash shell supports /dev/tcp.... kind of evil but you can make
>> >> connections and send strings via file redirection with it.
>> > 
>> > 
>> > so, on the 'how broken is that' scale, where does this one go?
>> > 
>> > the scale, btw, goes from 1 to 11
>> Around 16.  
>> ...
> 
> Why don't you just make ten louder and make ten be the top...

Re: [9fans] Van Jacobsen's network stack restructure

[ems]

I think what he was saying, is if you make the volume of 10 equal what
currently is 11 you would have the same effect, using different words.

On Thu, 2006-02-02 at 11:48 -0500, Brantley Coile wrote:
> But, this is 11!
> 
> > On Thu Feb  2 03:24:33 EST 2006, uriel@cat-v.org wrote:
> >> > David Leimbach wrote:
> >> > 
> >> >> The bash shell supports /dev/tcp.... kind of evil but you can make
> >> >> connections and send strings via file redirection with it.
> >> > 
> >> > 
> >> > so, on the 'how broken is that' scale, where does this one go?
> >> > 
> >> > the scale, btw, goes from 1 to 11
> >> Around 16.  
> >> ...
> > 
> > Why don't you just make ten louder and make ten be the top...

Re: [9fans] Van Jacobsen's network stack restructure

[andrey mirtchovski]

On 2/2/06, ems <oat@iinet.net.au> wrote:
> I think what he was saying, is if you make the volume of 10 equal what
> currently is 11 you would have the same effect, using different words.
>

Well, it's one louder, isn't it? It's not ten. You see, most blokes,
you know, will be playing at ten. You're on ten here, all the way up,
all the way up, all the way up, you're on ten on your guitar. Where
can you go from there? Where?

Re: [9fans] Van Jacobsen's network stack restructure

[Brantley Coile]

For those who are now really confused, check out the movie `Spinal Tap.'

> On 2/2/06, ems <oat@iinet.net.au> wrote:
>> I think what he was saying, is if you make the volume of 10 equal what
>> currently is 11 you would have the same effect, using different words.
>>
> 
> Well, it's one louder, isn't it? It's not ten. You see, most blokes,
> you know, will be playing at ten. You're on ten here, all the way up,
> all the way up, all the way up, you're on ten on your guitar. Where
> can you go from there? Where?

Re: [9fans] Van Jacobsen's network stack restructure

[jmk]

On Thu Feb  2 13:25:25 EST 2006, mirtchovski@gmail.com wrote:
> On 2/2/06, ems <oat@iinet.net.au> wrote:
> > I think what he was saying, is if you make the volume of 10 equal what
> > currently is 11 you would have the same effect, using different words.
> >
> 
> Well, it's one louder, isn't it? It's not ten. You see, most blokes,
> you know, will be playing at ten. You're on ten here, all the way up,
> all the way up, all the way up, you're on ten on your guitar. Where
> can you go from there? Where?

Nowhere. Exactly. What we do is if we need that extra...push over
the cliff...you know what we do?

Re: [9fans] Van Jacobsen's network stack restructure

[Dan Cross]

On Thu, Feb 02, 2006 at 02:39:00PM -0500, jmk@plan9.bell-labs.com wrote:
> Nowhere. Exactly. What we do is if we need that extra...push over
> the cliff...you know what we do?

Hey, this is Spinal Tap, baby!

	- Dan C.

Re: [9fans] Van Jacobsen's network stack restructure

[David Leimbach]

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

On 2/2/06, ems <oat@iinet.net.au> wrote:
>
> I think what he was saying, is if you make the volume of 10 equal what
> currently is 11 you would have the same effect, using different words.



Not a fan of Spinal Tap eh? :)

-- Dave

[-- Attachment #2: Type: text/html, Size: 532 bytes --]

Re: [9fans] Van Jacobsen's network stack restructure

[Andy Newman]

> But, this is 11!

Ha!  An old Armstrong hi-fi amp my father owned
went to 12.  So there.

(makes some sense given the clock analogy to rotary
potentiometers).

(Yes, know all about Spinal Tap, I'm a bass player.
No foil-wrapper-cucumber jokes okay!)

Re: [9fans] Van Jacobsen's network stack restructure

[ems]

Log of a conversation in #GNU
----
* Now talking on #gnu
* Topic for #gnu is: GNU's Not Unix | Help us finish GNU! See
http://gnu.org/s/packaging | Pledge to never buy Digital Restriction
Management encumbered media: http://www.pledgebank.com/boycottdrm/ |
Ututo is a Free Software GNU/Linux distribution recommended, among
others: http://www.gnu.org/links/links.html#FreeGNULinuxDistributions
* Topic for #gnu set by Lord_Odd_Eye at Sun Jan 15 10:46:19 2006
-ChanServ- [#gnu] Welcome to #GNU (Free Software Foundation), for
friendly discussion between GNU developers and queries regarding free
software/licensing.
oat Look at litch's whois
oat mainly his ircname
chillywilly that's pretty lame
chillywilly GNU's Not Unix
oat So that is why it sucks?
chillywilly trollin are we?
oat Why does bash and gawk have their own /dev/tcp ?
ams Because they want to.
* chillywilly makes use of /ignore
chillywilly lalala
oat ams: good reason :)
oat ams: Wouldn't it be simpler to add it to the kernel, like Plan 9?
ams To which kernel?
oat instead of adding it to every application
oat ams: GNU
oat (Hurd)
ams The Hurd isn't a `kernel'.
ams GNU Mach is the kernel, and adding such functionality there would be
silly.
ams gawk/bash did it half right, right space, wrong program.
ams Night!
* holzplatten (n=user@85.137.123.143) has joined #gnu
chillywilly what's happening on the L4 front?
oat ams: didn't Unix prove that wrong, "do one thing, and do it well" ?
oat Instead of, "do everything, everywhere, poorly"
ams oat, If you ever knew UNIX, then you would know that this isn't the
philosophy of unix.
ams Night.
chillywilly g'night ams
chillywilly hmmm, l4 cvs repo looks stagnant
oat ams: Okay, then it was the 'philosophy' of the Unix developers
oat ams: Good night, then.
-----
The format isn't that friendly to follow. The nickname is shown before
what they said.

P.S. 'hype' pointed out 'litch' ircname was 'Gay Niggerz United.'

On Thu, 2006-02-02 at 09:24 +0100, uriel@cat-v.org wrote:
> > David Leimbach wrote:
> > 
> >> The bash shell supports /dev/tcp.... kind of evil but you can make
> >> connections and send strings via file redirection with it.
> > 
> > 
> > so, on the 'how broken is that' scale, where does this one go?
> > 
> > the scale, btw, goes from 1 to 11
> Around 16.  
> 
> Gawk also has this "feature", wont be long before someone adds
> it to cat(1)... 
> 
> "do one thing, and do it well" has become
> "do everything, everywhere, poorly"
> 
> I have been wondering lately why don't the FSF replace the whole Hurd
> with bash, it even has emacs(nee libreadline) built in!
> 
> All features built into a single program, and then use some sort of
> virtualization to provide isolation...  and the software industry has
> gone full circle once more.
> 
> Some times I wonder if any progress is possible, or for every step forward
> we take, we will grow an extra leg that takes us back to square zero.
> 
> uriel

Re: [9fans] Van Jacobsen's network stack restructure

[David Leimbach]

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

On 2/1/06, Ronald G Minnich <rminnich@lanl.gov> wrote:
>
> David Leimbach wrote:
>
> > The bash shell supports /dev/tcp.... kind of evil but you can make
> > connections and send strings via file redirection with it.
>
>
> so, on the 'how broken is that' scale, where does this one go?
>
> the scale, btw, goes from 1 to 11
>
> ron


Well, I've used it to send some data down to a server in a pinch before...
when testing things like xinetd servers etc etc.

It works kind of sort of Ok :)

Someone did an IRC client in bash with it once... don't know where that is
anymore.

For curiosity's sake:

http://www.tldp.org/LDP/abs/html/devref1.html

In fact I'm rather ashamed to admit I've done more network programming with
/dev/tcp in bash than I have with Plan 9 or Inferno :).  The whole clone
concept hasn't sunk in for me yet.

Some things just still don't feel *right* to me being done through the
filesystem.  Seems like a square peg in a round hole kind of abstraction
sometimes.  But *shrug*, it's probably cleaner than sockets :)

Keep in mind I spent about 2 years working with Sandia Portals a few years
back, so I've got all these whacky RDMA ideas now. :)

Dave

[-- Attachment #2: Type: text/html, Size: 1625 bytes --]

Re: [9fans] Van Jacobsen's network stack restructure

[C H Forsyth]

> Some things just still don't feel *right* to me being done through the
> filesystem.  Seems like a square peg in a round hole kind of abstraction
> sometimes.

can you expand on that?

Re: [9fans] Van Jacobsen's network stack restructure

[David Leimbach]

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

On 2/2/06, C H Forsyth <forsyth@vitanuova.com> wrote:
>
> > Some things just still don't feel *right* to me being done through the
> > filesystem.  Seems like a square peg in a round hole kind of abstraction
> > sometimes.
>
> can you expand on that?
>
>
I'm sure it's just because of the general popularity of "sockets"
programming that makes it easier for me to visualize how one program
connects to another and then talks across that connection.

With sockets this seems very explicit... perhaps too explicit?

I've really not dug in deep into 9P2000 to really appreciate why this is
better yet I guess.

I have to learn more about channels and cloning in general to really "get
it" I guess.

Dave

[-- Attachment #2: Type: text/html, Size: 1063 bytes --]

Re: [9fans] Van Jacobsen's network stack restructure

[Charles Forsyth]

> I've really not dug in deep into 9P2000 to really appreciate why this is
> better yet I guess.

this is hardly exhaustive, but amongst other things,
	import $cpu /net
is rather more tedious in socket land.  another variant:
	import -a $cpu /net
to extend my machine's protocol set by those of $cpu, so that
i use my protocols when i can, but fall back to $cpu's when needed.

also, each type of socket has its own equivalent to sockaddr_in, so
that socket programs are often confined to a particular type of
network.  by contrast, plan 9's telnet can be used (and has been used)
across many network types, because dial is just an encapsulation of a
little dance that culminates in
	opening a file with a conventional name (clone)
	writing a string with a conventional form into that file   "connect address"
where the key thing is that "address" is a string, thus easily handled within a program
and conveyed between programs without knowledge of its meaning, but the string's
final recipient interprets it.  thus, in plan 9, ndb/cs translates human-readable strings
into little recipes of the form ``open this file, and write this string into it''; the essential
level of indirection is trivial to add (but not trivial to invent--it took some time).
the low-level addresses thus pass transparently through the application.

by contrast, i know one project that needed to switch networks transparently,
and with sockets, it was hard.  even replacing the library was not enough,
because the new addresses were bigger than could fit in the sockaddr_in
of the time, and so some amazing hacks were employed to work round that.

Re: [9fans] Van Jacobsen's network stack restructure

[Charles Forsyth]

oh.  that reminds me.  because we've got a new law on religious
hatred, i must include the standard disclaimer to
emphasise that my comments are in no way intended
to cause you to find the nearest penguin and damage its sockets.
that's well out of order.

Re: [9fans] Van Jacobsen's network stack restructure

[Ronald G Minnich]

David Leimbach wrote:

> I have to learn more about channels and cloning in general to really 
> "get it" I guess.

Dave, it's not that sockets are in a file system. It's that the 
interface to everything on plan 9 is the same -- in-kernel devices and 
out-of-kernel servers. So, in a very real sense, I talk to the sockets 
device the same way I talk to the RTC and the same way I talk over 9p to 
fossil -- and, hence, it looks like a file system. The set of ops for 
in-kernel devices looks pretty much the same as 9P ops. It's well worth 
reading.

Here's just one example why this can be nice. Every time we've needed a 
new address family on Unix or Linux -- think IPV6 or Infiniband -- we 
have to define a new set of binary structures, and then EVERY program 
that uses a sockaddr or library has to be hacked to deal with it. Just 
note that on linux 2.6.14,
ifconfig ib0 (infiniband iface)
and
cat /sys/class/net/ib0/address (or whatever the hell it is today)

give you DIFFERENT values for the MAC address. The ifconfig is missing 
(IIRC) 4 octets. This would not happen on Plan 9, because the string for 
the MAC would come straight out of the driver -- all programs, libaries, 
and so on will see the same thing. No binary interface, no kludgy 
case-variant structs, and so on.

A lot of unix or linux folks have not gotten this important point. It's 
not that everything goes in a file system, including device interfaces. 
It's that the interface to everything is the same -- including device 
interfaces. It's a very important distinction. It's also almost 
impossible to back-fit it into Unices at this point.

ron
p.s. I'm watching a great show on huge machines -- cranes, diggers, and 
so on. This looks more fun than computers to me just now. This one crane 
picked up the millenium bridge. Nice.

Re: [9fans] Van Jacobsen's network stack restructure

[erik quanstrom]

ron, 

having worked on stuff like this (on a little smaller scale),
i don't think you need to be envious.

huge is impressive for about so long. you get used to it.

writing software is about ideas. ideas are always exciting ---
there are always new ones.

- erik


Ronald G Minnich <rminnich@lanl.gov> writes

| p.s. I'm watching a great show on huge machines -- cranes, diggers, and 
| so on. This looks more fun than computers to me just now. This one crane 
| picked up the millenium bridge. Nice.

Re: [9fans] Van Jacobsen's network stack restructure

[andrey mirtchovski]

this thread definitely went to 11 :)

Re: [9fans] Van Jacobsen's network stack restructure

[ems]

Okay, we know how broken GNU is. But how about, how broken are GNU
leaders/developers are?

Scale is from 1 to 11. :)

On Thu, 2006-02-02 at 21:07 -0700, andrey mirtchovski wrote:
> this thread definitely went to 11 :)

Re: [9fans] Van Jacobsen's network stack restructure

[andrey mirtchovski]

On 2/2/06, ems <oat@iinet.net.au> wrote:
> Okay, we know how broken GNU is. But how about, how broken are GNU
> leaders/developers are?
>
> Scale is from 1 to 11. :)
>

Nigel Tufnel: [pause] These go to eleven.

Re: [9fans] Van Jacobsen's network stack restructure

[Dave Eckhardt]

One way to look at VJ's proposal is as a way for every application
on a machine to break modularity and do its own TCP to increase
performance.  From time to time this has been big fun in the
supercomputing arena (for example, back when "gigabit networking"
was an NSF-funded research challenge).  Of course, there are problems
when network connections stop being file descriptors like everything
else.

In terms of Plan 9 maybe there is a different message.  We like
TCP connections being files in a small file system, but does that
file system *have* to be provided by the kernel?  If he can do
it with good performance, the result would be more fun to debug
and replace.

Dave Eckhardt

Re: [9fans] Van Jacobsen's network stack restructure

[rog]

> One way to look at VJ's proposal is as a way for every application
> on a machine to break modularity and do its own TCP to increase
> performance.

to me it looked more like he was calling for more processing to be
done in the context of the user process (hence using its current
processor), rather than by some central loop (say etherread4()).
this doesn't mean it can't be done in kernel mode.

(i suppose you'd save a syscall by doing it in a library, but you'd
instantly lose all the abstraction that fds give you, as everyone's
pointed out.)

i imagine that you might get fairly close to his proposal within plan
9 by changing the path between the ``read medium'' loop and the
eventual ipread, putting most of the ip processing within ipread()
with only some signature checking in the medium reading process, and a
non-locking shared memory interface between them (i.e.  not a Queue).

assuming the processing done in ipiput4 is significant, one could see
how this might speed things up, by upping the turnaround time of the
etherread loop which is potentially acting as a bottleneck.

but that's only from an extremely brief glance at the code - i'm
talking from a position of near-total ignorance here, i'm afraid!

(BTW, can plan 9 actually use multi-core processors?)

Re: [9fans] Van Jacobsen's network stack restructure

[geoff]

> (BTW, can plan 9 actually use multi-core processors?)

In principle, yes, since they are just shared-memory multiprocessors
packaged more compactly than previously.

Having said that, I don't know if Intel and AMD did the obvious thing
and just populated the MP table appropriately or whether they felt
compelled to gratuitously do things differently because the word
`core' is spelled differently than the word `processor', thus
necessitating at least minor kernel changes.  Given Intel's past
behaviour, I'm pessimistic.

Re: [9fans] Van Jacobsen's network stack restructure

[jmk]

we've already bumped into this, some motherboards with intel
hyperthreaded processors have a bios mp table and some don't.
when i started the amd64 port i decided to not bother about
the mp stuff for the moment and once it was working then do the
mp stuff anew (it is ~10 years old and crufty) and not rely on
the bios. i'm about ready to do that now and it should cover
both intel and amd processors.

--jim

On Fri Feb 10 20:26:43 EST 2006, geoff@collyer.net wrote:
> > (BTW, can plan 9 actually use multi-core processors?)
> 
> In principle, yes, since they are just shared-memory multiprocessors
> packaged more compactly than previously.
> 
> Having said that, I don't know if Intel and AMD did the obvious thing
> and just populated the MP table appropriately or whether they felt
> compelled to gratuitously do things differently because the word
> `core' is spelled differently than the word `processor', thus
> necessitating at least minor kernel changes.  Given Intel's past
> behaviour, I'm pessimistic.

Re: [9fans] Van Jacobsen's network stack restructure

[Paweł Lasek]

On 2/11/06, geoff@collyer.net <geoff@collyer.net> wrote:
> > (BTW, can plan 9 actually use multi-core processors?)
>
> In principle, yes, since they are just shared-memory multiprocessors
> packaged more compactly than previously.
>
> Having said that, I don't know if Intel and AMD did the obvious thing
> and just populated the MP table appropriately or whether they felt
> compelled to gratuitously do things differently because the word
> `core' is spelled differently than the word `processor', thus
> necessitating at least minor kernel changes.  Given Intel's past
> behaviour, I'm pessimistic.

From my knowledge, AMD64 populates ACPI cpu tables with all
processors, including every core - the only oddity might be info about
where those 'cores' are - Since AMD64 is a NUMA, it should be
somewhere :)

However, it all depends on BIOS (although those motherboards which
boast the sign 'dual-core support' should include it) and what I said
complies to 64-bit mode. In 32-bit, it should present standard Intel
MP 1.4 tables.... I think :P


--
Paweł Lasek

Re: [9fans] Van Jacobsen's network stack restructure

[jmk]

Last week I booted Plan 9 on one of Ron Minnich's dual-core
dual-processor AMD systems without trouble. It was an Iwill DK8-HTX
motherboard with an MPS 1.4 table supplied by the BIOS. Ron had
less success booting Redhat on it, the kernel seg faulted.

It's getting harder to ignore bloat like API, though.

--jim

On Mon Feb 20 15:41:17 EST 2006, pawel.lasek@gmail.com wrote:
> On 2/11/06, geoff@collyer.net <geoff@collyer.net> wrote:
> > > (BTW, can plan 9 actually use multi-core processors?)
> >
> > In principle, yes, since they are just shared-memory multiprocessors
> > packaged more compactly than previously.
> >
> > Having said that, I don't know if Intel and AMD did the obvious thing
> > and just populated the MP table appropriately or whether they felt
> > compelled to gratuitously do things differently because the word
> > `core' is spelled differently than the word `processor', thus
> > necessitating at least minor kernel changes.  Given Intel's past
> > behaviour, I'm pessimistic.
> 
> From my knowledge, AMD64 populates ACPI cpu tables with all
> processors, including every core - the only oddity might be info about
> where those 'cores' are - Since AMD64 is a NUMA, it should be
> somewhere :)
> 
> However, it all depends on BIOS (although those motherboards which
> boast the sign 'dual-core support' should include it) and what I said
> complies to 64-bit mode. In 32-bit, it should present standard Intel
> MP 1.4 tables.... I think :P
> 
> 
> --
> Paweł Lasek

Re: [9fans] Van Jacobsen's network stack restructure

[Ronald G Minnich]

jmk@plan9.bell-labs.com wrote:
> Last week I booted Plan 9 on one of Ron Minnich's dual-core
> dual-processor AMD systems without trouble. It was an Iwill DK8-HTX
> motherboard with an MPS 1.4 table supplied by the BIOS. Ron had
> less success booting Redhat on it, the kernel seg faulted.

yes, and what was funny, it was the FC4 *install* disk. yikes.
Ubuntu worked better.

It used to be that Red hat on a K7 would boot, then install a kernel 
that would blow up (accessed an MSR that did not exist on K7). Progress! 
We can no longer install a bad kernel :-)

ron

Re: [9fans] Van Jacobsen's network stack restructure

[Charles Forsyth]

> yes, and what was funny, it was the FC4 *install* disk. yikes.
> Ubuntu worked better.

as far as i can tell, Ubuntu always works at least as well and often better.

Re: [9fans] Van Jacobsen's network stack restructure

[Ronald G Minnich]

quanstro@quanstro.net wrote:
> c'mon. linux has consistently gone the other way on this issue.
> linux doesn't even have a device node for network interfaces.


for grins, I just did a grep, and find at least 41 options now for the 
network stack in linux.

Too many knobs for me. The # of knobs is rapidly reaching my age -- 
oops, I should not say that.

ron

Re: [9fans] Van Jacobsen's network stack restructure

[quanstro]

what the bash shell supports and what linux kernel supports are, after all,
two seperate and not necessiarly related things.

bash runs on more than linux, after all.

- erik

On Wed Feb  1 18:50:13 CST 2006, leimy2k@gmail.com wrote:
> On 2/1/06, quanstro@quanstro.net <quanstro@quanstro.net> wrote:
> > c'mon. linux has consistently gone the other way on this issue.
> > linux doesn't even have a device node for network interfaces.
> >
> > i don't know anything about the reasoning for this. efficiency?
> > support for a static /dev? i don't know.
> >
> 
> The bash shell supports /dev/tcp.... kind of evil but you can make
> connections and send strings via file redirection with it.
> 
> Dave
> 

Re: [9fans] Van Jacobsen's network stack restructure

[quanstro]

On Wed Feb  1 18:49:24 CST 2006, leimy2k@gmail.com wrote:
> >
> > i don't know anything about the reasoning for this. efficiency?
> > support for a static /dev? i don't know.
> 
> Probably because they don't have a single devfs they can agree on?
> 

that assumes that there was a dynamic /dev when networking was
added.

nobody was even thinking about dynamic devices when networking
was added to linux

- erik

Re: [9fans] Van Jacobsen's network stack restructure

[Russ Cox]

> nobody was even thinking about dynamic devices when networking
> was added to linux

s/linux/the original bsd/
s/dynamic //
in fact, s/about devices //

Re: [9fans] Van Jacobsen's network stack restructure

[ems]

While your at it.

s/nobody/none of the linux or BSD developers/
On Wed, 2006-02-01 at 20:27 -0500, Russ Cox wrote:
> > nobody was even thinking about dynamic devices when networking
> > was added to linux
> 
> s/linux/the original bsd/
> s/dynamic //
> in fact, s/about devices //

Re: [9fans] Van Jacobsen's network stack restructure

[George Michaelson]

$ sysctl net.inet.ip|wc -l
      23
$ sysctl net.inet.tcp|wc -l
      28
$ sysctl net.inet.udp|wc -l
       4
$ sysctl net.inet.arp|wc -l
       4
$ uname -a
NetBSD garlic.apnic.net 3.99.15 NetBSD 3.99.15 (GGMSMALL-NOV6) #0: Tue Jan 24 09:14:58 EST 2006  root@:/data/Build/src/sys/arch/i386/compile/GGMSMALL-NOV6 i386
$

So thats 23 knobs in the kernel for ip, another 28 for tcp, 4 for udp,
and 4 for arp.

Since udp does no backoff or e2e flow control, its hardly surprising it
doesn't have much tuning.

Since tcp does, its also hardly surprising it has at least *some*
options

To be fair, at least some of the knobs will come from IETF driven
tweaks. if 9 doesn't let you frob with them, that doesn't have to be
good. (moving from cable to wifi and VPN I sometimes want to at least
alter my MTU and frag behaviour. pMTU is broken for a lot of places and
tunnelling hurts with fragments)

-G

Re: [9fans] Van Jacobsen's network stack restructure

[quanstro]

it could have been worse. they could have had a builtin "socket"; 
given the universe of possibly ways networking sockets could have been
introduced to bash, this is probablly better than par.

- erik

On Wed Feb  1 20:17:42 CST 2006, rminnich@lanl.gov wrote:
> David Leimbach wrote:
> 
> > The bash shell supports /dev/tcp.... kind of evil but you can make
> > connections and send strings via file redirection with it.
> 
> 
> so, on the 'how broken is that' scale, where does this one go?
> 
> the scale, btw, goes from 1 to 11
> 
> ron

Re: [9fans] Van Jacobsen's network stack restructure

[quanstro]

more fundamentally, bsd missed the point of unix. what file does
a socket fd reference?

- erik

On Wed Feb  1 19:32:00 CST 2006, rsc@swtch.com wrote:
> > nobody was even thinking about dynamic devices when networking
> > was added to linux
> 
> s/linux/the original bsd/
> s/dynamic //
> in fact, s/about devices //
> 

Re: [9fans] Van Jacobsen's network stack restructure

[Derek Fawcus]

On Wed, Feb 01, 2006 at 08:50:14PM +0000, quanstro@quanstro.net wrote:
> more fundamentally, bsd missed the point of unix. what file does
> a socket fd reference?

Hmm.  It seems to a large extent they (and linux definitly) have moved
from "everything is a file" to "everything is a file descriptor".

DF

> 
> - erik
> 
> On Wed Feb  1 19:32:00 CST 2006, rsc@swtch.com wrote:
> > > nobody was even thinking about dynamic devices when networking
> > > was added to linux
> > 
> > s/linux/the original bsd/
> > s/dynamic //
> > in fact, s/about devices //
> > 

Re: [9fans] Van Jacobsen's network stack restructure

[quanstro]

you have successfully reinvented multics with networking.

some people have done page-based distributed shared memory along
these lines.

the problem with distribution is that you need some protocol
involving naming to send the pages around. which ends up looking quite a bit
like a file protocol. with One True addressing scheme.

- erik

On Thu Feb  2 13:24:19 CST 2006, leimy2k@gmail.com wrote:

> And with 64bit Virtual Memory why not mmap everything? [except for the
> thrashing on my poor hard disk and lack of terrabytes of physical memory :)]
> 
> I jokingly have been saying this to only close personal friends for a while.
> 
> Why can't I mmap a remote process's memory?  Some embedded systems [used
> to?] let me do this and pass messages with memcpy :).
> 
> Throw off the shackles of "read" and "write" calls.... use mmap instead :)
> 
> *chuckle*
> 

Re: [9fans] Van Jacobsen's network stack restructure

[quanstro]

On Thu Feb  2 11:57:10 CST 2006, forsyth@vitanuova.com wrote:
> yes, i supposed it could be something along those lines but i didn't make my point clear.
> if it is along those lines, it breaks something that even sockets didn't break.
> at the moment, i get a file descriptor that i can pass to anything that does read and write.

definately not true on linux. udp and netlink sockets would be a counter example.

> now i've got something that i can only mmap, and even the mmap refers to a
> non-trivial data structure shared with the kernel, and the recipient of the file descriptor
> must invoke special calls in a special library (ie, the `access method').
> i suppose you could call it TCAM
> 

i think you're confusing "moving" bytes around with using said bytes with a context.

any file that you read or write can be viewed as either a series of bytes or a complicated
data structure. either mmap or read/write will let you do that.

take /etc/passwd on linux. you can read(2) it or you can use setpwent/getpwent/endpwent
if you'd like to view it as a data structure.

- erik

Re: [9fans] Van Jacobsen's network stack restructure

[geoff]

No, I think Charles has a good point about TCAM.  In the brave new VJ
world, how does a process know if its standard input (file descriptor
0) is a normal descriptor or a magic VJ-channel descriptor?  It has to
know in order to know if it should call read(0, ...) or
read_vj_chan(0, ...), and that in turn returns us to RSX-11 land:
different system calls for different kinds of files.

One could try to minimise the disruption by having a tcp file server
process that reads and writes VJ-channels (and only that process would
read and write tcp VJ-channels), does tcp processing, and reads and
writes ordinary file descriptors to its clients, but that hurts the
attempt to minimise copying by using VJ channels.  Actually you might
have to have a tcp file server process (or equivalent) since tcp might
want to keep state across all concurrent tcp connections.

Using lock-free data structures might be worth pursuing.

I worry a little about letting user processes diddle tcp headers
directly.  I don't immediately see a security hazard, but I can't
swear that there isn't one.

Re: [9fans] Van Jacobsen's network stack restructure

[George Michaelson]

can you live with iotctl() like mechanisms to do what one might call
'out of band' signalling to say the open FD in filespace has special
properties?

could you name the filespaces to determine which settings are used?

It all seems a bit artificial to me. But if the key issue is that you
want any arbitrary process to be able to do

	(f)open() ... read/write .. (f)close() on a name, then you
either dick with the name, or dick with the open FD, or invoke the gods.

sockets() in some ways was about deliberately breaking the model to
make things like ioctl() more plausibly tenable. Who really cares if
you have to setsockopt() once you bought into having to do the whole
socket() thing in the first place?

-G

Re: [9fans] Van Jacobsen's network stack restructure

[Russ Cox]

> definately not true on linux. udp and netlink
> sockets would be a counter example.

linux being broken is a bad argument for breaking it further.

russ

Re: [9fans] Van Jacobsen's network stack restructure

[Aki M Nyrhinen]

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

On Thu, Feb 02, 2006 at 05:43:49PM +0000, quanstro@quanstro.net wrote:
> On Thu Feb  2 11:57:10 CST 2006, forsyth@vitanuova.com wrote:
> > yes, i supposed it could be something along those lines but i didn't make my point clear.
> > if it is along those lines, it breaks something that even sockets didn't break.
> > at the moment, i get a file descriptor that i can pass to anything that does read and write.
> 
> definately not true on linux. udp and netlink sockets would be a counter example.

sorry, are you claiming that the attached program (horror.c) does not
work on (some) linux?

this is what in my understanding VJ's stuff would break.

	Aki


[-- Attachment #2: horror.c --]
[-- Type: text/plain, Size: 567 bytes --]


#include <sys/socket.h>
#include <netinet/in.h>
#include <unistd.h>

int
main(void)
{
	int fd;
	struct sockaddr_in sa;
	sa.sin_family = AF_INET;
	sa.sin_addr.s_addr = htonl(0x7F000001);
	sa.sin_port = htons(5555);
	switch(fork()){
	case 0:
		fd = socket(PF_INET, SOCK_DGRAM, 0);
		bind(fd, (struct sockaddr*)&sa, sizeof sa);
		dup2(fd, 0);
		execl("/bin/cat", "cat", NULL);
	default:
		fd = socket(PF_INET, SOCK_DGRAM, 0);
		connect(fd, (struct sockaddr*)&sa, sizeof sa);
		dup2(fd, 1);
		execl("/bin/cat", "cat", NULL);
	}
	return 0;
}

Re: [9fans] Van Jacobsen's network stack restructure

[Marina Brown]

Aki M Nyrhinen wrote:

>On Thu, Feb 02, 2006 at 05:43:49PM +0000, quanstro@quanstro.net wrote:
>  
>
>>On Thu Feb  2 11:57:10 CST 2006, forsyth@vitanuova.com wrote:
>>    
>>
>>>yes, i supposed it could be something along those lines but i didn't make my point clear.
>>>if it is along those lines, it breaks something that even sockets didn't break.
>>>at the moment, i get a file descriptor that i can pass to anything that does read and write.
>>>      
>>>
>>definately not true on linux. udp and netlink sockets would be a counter example.
>>    
>>
>
>sorry, are you claiming that the attached program (horror.c) does not
>work on (some) linux?
>
>  
>

Works on my ubantu linux box and a freebsd 5.2.1 box i have.

-- Marina Brown

>this is what in my understanding VJ's stuff would break.
>
>	Aki
>
>  
>
>------------------------------------------------------------------------
>
>
>#include <sys/socket.h>
>#include <netinet/in.h>
>#include <unistd.h>
>
>int
>main(void)
>{
>	int fd;
>	struct sockaddr_in sa;
>	sa.sin_family = AF_INET;
>	sa.sin_addr.s_addr = htonl(0x7F000001);
>	sa.sin_port = htons(5555);
>	switch(fork()){
>	case 0:
>		fd = socket(PF_INET, SOCK_DGRAM, 0);
>		bind(fd, (struct sockaddr*)&sa, sizeof sa);
>		dup2(fd, 0);
>		execl("/bin/cat", "cat", NULL);
>	default:
>		fd = socket(PF_INET, SOCK_DGRAM, 0);
>		connect(fd, (struct sockaddr*)&sa, sizeof sa);
>		dup2(fd, 1);
>		execl("/bin/cat", "cat", NULL);
>	}
>	return 0;
>}
>
>  
>

Re: [9fans] Van Jacobsen's network stack restructure

[quanstro]

i thought it was clear i was arguing the opposite.

- erik

On Thu Feb  2 18:32:08 CST 2006, rsc@swtch.com wrote:
> > definately not true on linux. udp and netlink
> > sockets would be a counter example.
> 
> linux being broken is a bad argument for breaking it further.
> 
> russ

Re: [9fans] Van Jacobsen's network stack restructure

[quanstro]

On Thu Feb  2 18:32:34 CST 2006, ggm@apnic.net wrote:
> 	(f)open() ... read/write .. (f)close() on a name, then you
> either dick with the name, or dick with the open FD, or invoke the gods.
> 
> sockets() in some ways was about deliberately breaking the model to
> make things like ioctl() more plausibly tenable. Who really cares if
> you have to setsockopt() once you bought into having to do the whole
> socket() thing in the first place?
> 
> -G

the argument that keeps coming up seems to be "you can write to a socket,
so how bad can it be". the corollary seems to be "you can pass the fd around".

i believe the corollary is false. how would you tell your favorite editor to open a file on
the other end of a socket?

it is a major problem that the network (with a socket interface) is outside the namespace.
it results in stuff like /dev/tcp in bash/gawk.

furthermore, it's not true that you can "just write" to a socket. for instance, udp
sockets cannot be written to. 

- erik

Re: [9fans] Van Jacobsen's network stack restructure

[Christopher Nielsen]

maybe i'm just thick headed, and possibly it's my fault for starting
this whole thing. but i'd like to know why we're talking about sockets
here?

the question i had was whether or not Plan 9 already has something
similar to VJ's ideas or if maybe we should look at the stack and
think about whether or not it makes sense to implement these ideas.

i think my question was answered: yes, it couldn't hurt to have a look
under the hood to see if it makes sense.

do we really have to keep discussing sockets? it's a terrible
interface. 'nuff said.

--
Christopher Nielsen
"They who can give up essential liberty for temporary
safety, deserve neither liberty nor safety." --Benjamin Franklin

Re: [9fans] Van Jacobsen's network stack restructure

[quanstro]

this doesn't work for me.

Re: [9fans] Van Jacobsen's network stack restructure

[Andrew Simmons]

At 01:31 p.m. 3/02/2006, you wrote:


> > Well, it's one louder, isn't it? It's not ten. You see, most blokes,
> > you know, will be playing at ten. You're on ten here, all the way up,
> > all the way up, all the way up, you're on ten on your guitar. Where
> > can you go from there? Where?
>
>Nowhere. Exactly. What we do is if we need that extra...push over
>the cliff...you know what we do?

Put it up to eleven?

Re: [9fans] Van Jacobsen's network stack restructure

[jmk]

On Thu Feb  2 22:32:23 EST 2006, andrew.simmons@monitorbm.co.nz wrote:
> At 01:31 p.m. 3/02/2006, you wrote:
> 
> 
> > > Well, it's one louder, isn't it? It's not ten. You see, most blokes,
> > > you know, will be playing at ten. You're on ten here, all the way up,
> > > all the way up, all the way up, you're on ten on your guitar. Where
> > > can you go from there? Where?
> >
> >Nowhere. Exactly. What we do is if we need that extra...push over
> >the cliff...you know what we do?
> 
> Put it up to eleven?

Eleven. Exactly. One louder.

Re: [9fans] Van Jacobsen's network stack restructure

[Andrew Simmons]

At 04:35 p.m. 3/02/2006, you wrote:
>On Thu Feb  2 22:32:23 EST 2006, andrew.simmons@monitorbm.co.nz wrote:
> > At 01:31 p.m. 3/02/2006, you wrote:
> >
> >
> > > > Well, it's one louder, isn't it? It's not ten. You see, most blokes,
> > > > you know, will be playing at ten. You're on ten here, all the way up,
> > > > all the way up, all the way up, you're on ten on your guitar. Where
> > > > can you go from there? Where?
> > >
> > >Nowhere. Exactly. What we do is if we need that extra...push over
> > >the cliff...you know what we do?
> >
> > Put it up to eleven?
>
>Eleven. Exactly. One louder.

Why don't you just make ten louder and make ten be the top... number... and 
make that a little louder?

Hang on, didn't some one already suggest that?

Re: [9fans] Van Jacobsen's network stack restructure

[ems]

On Fri, 2006-02-03 at 16:41 +1300, Andrew Simmons wrote:
> At 04:35 p.m. 3/02/2006, you wrote:
> >On Thu Feb  2 22:32:23 EST 2006, andrew.simmons@monitorbm.co.nz wrote:
> > > At 01:31 p.m. 3/02/2006, you wrote:
> > >
> > >
> > > > > Well, it's one louder, isn't it? It's not ten. You see, most blokes,
> > > > > you know, will be playing at ten. You're on ten here, all the way up,
> > > > > all the way up, all the way up, you're on ten on your guitar. Where
> > > > > can you go from there? Where?
> > > >
> > > >Nowhere. Exactly. What we do is if we need that extra...push over
> > > >the cliff...you know what we do?
> > >
> > > Put it up to eleven?
> >
> >Eleven. Exactly. One louder.
> 
> Why don't you just make ten louder and make ten be the top... number... and 
> make that a little louder?
> 
> Hang on, didn't some one already suggest that?

Yea, I did.

Re: [9fans] Van Jacobsen's network stack restructure

["Nils O. Selåsdal"]

results in stuff like /dev/tcp in bash/gawk.
> 
> furthermore, it's not true that you can "just write" to a socket. for instance, udp
> sockets cannot be written to. 
You should be able to write(2) to an UDP socket which
you've connect(2) and bind(2) atleat.