9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: David Leimbach <leimy2k@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] Van Jacobsen's network stack restructure
Date: Thu,  2 Feb 2006 11:21:02 -0800	[thread overview]
Message-ID: <3e1162e60602021121p2bda91cu5bbaa3ff8467cf78@mail.gmail.com> (raw)
In-Reply-To: <200602021816.k12IGrSH080631@gate.bitblocks.com>

[-- 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 --]

  reply	other threads:[~2006-02-02 19:21 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-01  4:28 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 [this message]
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"

Reply instructions:

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

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

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

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

  git send-email \
    --in-reply-to=3e1162e60602021121p2bda91cu5bbaa3ff8467cf78@mail.gmail.com \
    --to=leimy2k@gmail.com \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

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

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).