9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* [9fans] Van Jacobsen's network stack restructure
@ 2006-02-01  4:28 Christopher Nielsen
  2006-02-01  5:57 ` ems
                   ` (2 more replies)
  0 siblings, 3 replies; 78+ messages in thread
From: Christopher Nielsen @ 2006-02-01  4:28 UTC (permalink / raw)
  To: 9fans

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

^ permalink raw reply	[flat|nested] 78+ messages in thread
* Re: [9fans] Van Jacobsen's network stack restructure
@ 2006-02-01 18:20 quanstro
  2006-02-02  0:48 ` David Leimbach
                   ` (2 more replies)
  0 siblings, 3 replies; 78+ messages in thread
From: quanstro @ 2006-02-01 18:20 UTC (permalink / raw)
  To: 9fans

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? ;)


^ permalink raw reply	[flat|nested] 78+ messages in thread
* Re: [9fans] Van Jacobsen's network stack restructure
@ 2006-02-01 18:55 quanstro
  0 siblings, 0 replies; 78+ messages in thread
From: quanstro @ 2006-02-01 18:55 UTC (permalink / raw)
  To: 9fans

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
> 


^ permalink raw reply	[flat|nested] 78+ messages in thread
* Re: [9fans] Van Jacobsen's network stack restructure
@ 2006-02-01 19:13 quanstro
  2006-02-02  1:27 ` Russ Cox
  0 siblings, 1 reply; 78+ messages in thread
From: quanstro @ 2006-02-01 19:13 UTC (permalink / raw)
  To: 9fans

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


^ permalink raw reply	[flat|nested] 78+ messages in thread
* Re: [9fans] Van Jacobsen's network stack restructure
@ 2006-02-01 20:35 quanstro
  0 siblings, 0 replies; 78+ messages in thread
From: quanstro @ 2006-02-01 20:35 UTC (permalink / raw)
  To: 9fans

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


^ permalink raw reply	[flat|nested] 78+ messages in thread
* Re: [9fans] Van Jacobsen's network stack restructure
@ 2006-02-01 20:50 quanstro
  2006-02-02 19:29 ` Derek Fawcus
  0 siblings, 1 reply; 78+ messages in thread
From: quanstro @ 2006-02-01 20:50 UTC (permalink / raw)
  To: 9fans

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 //
> 


^ permalink raw reply	[flat|nested] 78+ messages in thread
* Re: [9fans] Van Jacobsen's network stack restructure
@ 2006-02-02 17:14 quanstro
  0 siblings, 0 replies; 78+ messages in thread
From: quanstro @ 2006-02-02 17:14 UTC (permalink / raw)
  To: 9fans

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*
> 


^ permalink raw reply	[flat|nested] 78+ messages in thread
* Re: [9fans] Van Jacobsen's network stack restructure
@ 2006-02-02 17:43 quanstro
  2006-02-03  0:24 ` geoff
                   ` (2 more replies)
  0 siblings, 3 replies; 78+ messages in thread
From: quanstro @ 2006-02-02 17:43 UTC (permalink / raw)
  To: 9fans

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


^ permalink raw reply	[flat|nested] 78+ messages in thread
* Re: [9fans] Van Jacobsen's network stack restructure
@ 2006-02-03  0:39 quanstro
  0 siblings, 0 replies; 78+ messages in thread
From: quanstro @ 2006-02-03  0:39 UTC (permalink / raw)
  To: 9fans

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


^ permalink raw reply	[flat|nested] 78+ messages in thread
* Re: [9fans] Van Jacobsen's network stack restructure
@ 2006-02-03  1:00 quanstro
  2006-02-03  1:11 ` Christopher Nielsen
  0 siblings, 1 reply; 78+ messages in thread
From: quanstro @ 2006-02-03  1:00 UTC (permalink / raw)
  To: 9fans

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


^ permalink raw reply	[flat|nested] 78+ messages in thread
* Re: [9fans] Van Jacobsen's network stack restructure
@ 2006-02-03  2:09 quanstro
  0 siblings, 0 replies; 78+ messages in thread
From: quanstro @ 2006-02-03  2:09 UTC (permalink / raw)
  To: 9fans

this doesn't work for me.



^ permalink raw reply	[flat|nested] 78+ messages in thread
[parent not found: <6.0.2.0.0.20060203132930.01c25178@pop.monitorbm.co.nz>]
[parent not found: <000101c6285f$54291320$14aaa8c0@utelsystems.local>]

end of thread, other threads:[~2006-02-20 23:30 UTC | newest]

Thread overview: 78+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-02-01  4:28 [9fans] Van Jacobsen's network stack restructure Christopher Nielsen
2006-02-01  5:57 ` ems
2006-02-01  6:00   ` Christopher Nielsen
2006-02-01  6:06     ` ems
2006-02-01  6:03   ` Federico G. Benavento
2006-02-01 17:46 ` uriel
2006-02-01 18:10   ` Skip Tavakkolian
2006-02-02 13:37 ` Charles Forsyth
2006-02-02 17:40   ` Bakul Shah
2006-02-02 18:01     ` C H Forsyth
2006-02-02 18:16       ` Bakul Shah
2006-02-02 19:21         ` David Leimbach
2006-02-03  3:44           ` Ronald G Minnich
2006-02-01 18:20 quanstro
2006-02-02  0:48 ` David Leimbach
2006-02-02  0:49 ` David Leimbach
2006-02-02  2:12   ` Ronald G Minnich
2006-02-02  2:22     ` Christopher Nielsen
2006-02-02  8:24     ` uriel
2006-02-02 10:35       ` Charles Forsyth
2006-02-02 11:40         ` ems
     [not found]         ` <000001c627ee$35f3aee0$14aaa8c0@utelsystems.local>
2006-02-02 12:33           ` "Nils O. Selåsdal"
2006-02-03  3:36         ` Ronald G Minnich
2006-02-03  3:44           ` erik quanstrom
2006-02-03  3:48           ` Christopher Nielsen
2006-02-02 14:36       ` jmk
2006-02-02 16:48         ` Brantley Coile
2006-02-02 18:20           ` ems
2006-02-02 18:24             ` andrey mirtchovski
2006-02-02 19:23               ` Brantley Coile
2006-02-02 19:39               ` jmk
2006-02-02 23:28                 ` Dan Cross
2006-02-02 19:16             ` David Leimbach
2006-02-02 21:28           ` Andy Newman
2006-02-03  3:38       ` ems
2006-02-02 16:59     ` David Leimbach
2006-02-02 17:21       ` C H Forsyth
2006-02-02 19:14         ` David Leimbach
2006-02-02 20:46           ` Charles Forsyth
2006-02-02 20:57             ` Charles Forsyth
2006-02-03  3:55           ` Ronald G Minnich
2006-02-03  4:06             ` erik quanstrom
2006-02-03  4:07             ` andrey mirtchovski
2006-02-03  4:12               ` ems
2006-02-03  4:25                 ` andrey mirtchovski
2006-02-06  4:25             ` Dave Eckhardt
2006-02-10 19:15               ` rog
2006-02-11  1:20                 ` geoff
2006-02-11  1:59                   ` jmk
2006-02-20 20:37                   ` Paweł Lasek
2006-02-20 20:54                     ` jmk
2006-02-20 23:11                       ` Ronald G Minnich
2006-02-20 23:30                         ` Charles Forsyth
2006-02-02  2:11 ` Ronald G Minnich
2006-02-01 18:55 quanstro
2006-02-01 19:13 quanstro
2006-02-02  1:27 ` Russ Cox
2006-02-02  2:01   ` ems
2006-02-02  2:44     ` George Michaelson
2006-02-01 20:35 quanstro
2006-02-01 20:50 quanstro
2006-02-02 19:29 ` Derek Fawcus
2006-02-02 17:14 quanstro
2006-02-02 17:43 quanstro
2006-02-03  0:24 ` geoff
2006-02-03  0:31   ` George Michaelson
2006-02-03  0:30 ` Russ Cox
2006-02-03  1:42 ` Aki M Nyrhinen
2006-02-03  3:33   ` Marina Brown
2006-02-03  0:39 quanstro
2006-02-03  1:00 quanstro
2006-02-03  1:11 ` Christopher Nielsen
2006-02-03  2:09 quanstro
     [not found] <6.0.2.0.0.20060203132930.01c25178@pop.monitorbm.co.nz>
2006-02-03  3:30 ` Andrew Simmons
2006-02-03  3:35   ` jmk
2006-02-03  3:41     ` Andrew Simmons
2006-02-03  3:45       ` ems
     [not found] <000101c6285f$54291320$14aaa8c0@utelsystems.local>
2006-02-03  7:20 ` "Nils O. Selåsdal"

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).