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 --]
next prev parent 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).