[9fans] mmap - Plan9

This is a discussion on [9fans] mmap - Plan9 ; > Does anyone have pointers to *nice* interfaces for doing this? I don't > care which OS, but I'd like to not have the implementation I'm > requesting suck because I missed some gotchas that someone else already hit. paul ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 28 of 28

Thread: [9fans] mmap

  1. Re: [9fans] mmap

    > Does anyone have pointers to *nice* interfaces for doing this? I don't
    > care which OS, but I'd like to not have the implementation I'm
    > requesting suck because I missed some gotchas that someone else already hit.


    paul lalonde's request is a good one, but i think a useful qualification
    is that it should also be shown in practice to have a reasonable implementation
    on several agreeably different architectures. one of the reasons mmap is
    bad is that like job control it whacked some vague ideas into an existing
    system without reference to its existing conventions, then vaguely extended
    it in a vague way from time to time, vaguely different from platform to platform,
    and with vague documentation. ``could they be any more vague?''



  2. Re: [9fans] mmap

    On Thu, 31 Jul 2008 22:39:43 BST Charles Forsyth wrote:
    > > Does anyone have pointers to *nice* interfaces for doing this? I don't
    > > care which OS, but I'd like to not have the implementation I'm
    > > requesting suck because I missed some gotchas that someone else already hit.

    >
    > paul lalonde's request is a good one, but i think a useful qualification is
    > that it should also be shown in practice to have a reasonable implementation
    > on several agreeably different architectures. one of the reasons mmap is
    > bad is that like job control it whacked some vague ideas into an existing
    > system without reference to its existing conventions, then vaguely extended
    > it in a vague way from time to time, vaguely different from platform to
    > platform, and with vague documentation. ``could they be any more vague?''


    I vaguely remember seeing a comment on Karels and McKusick's
    original mmap proposal (about 20 years ago). I think it was
    by dmr. Something to the effect that if such a facility is
    desired it should be made as integral to the OS as an inode
    is to Unix (and not bolted on the side). Makes for an
    interesting thought experiment as potentially all sorts of
    simplifications are possible.


  3. Re: [9fans] mmap

    here is a thought:

    the kernel does mmap for code/data. This is because we think of a file
    as a segment of data that somehow maps well to a segment of memory.

    You wouldn't execute code from a stream, now, would you?

    Well, this: http://www.ambric.com/

    has hardware channels. And you can
    call from channel
    and execute code being sent down a channel to you from another cpu.

    There's no real analogue to this in any OS I've used for a while ...

    You could write the mcilroy sieve in this very directly. You could
    even, when starting a new thread, push the code down to the next cpu.
    And that cpu is paused in a call from channel until it gets its code.
    A nice way to keep them idle until you need them.

    it's a very interesting architecture, to say the least. For me anyway
    the most novel thing I've seen in a while.

    ron


  4. Re: [9fans] mmap

    On Thu, Jul 31, 2008 at 5:32 PM, ron minnich wrote:

    > here is a thought:
    >
    > the kernel does mmap for code/data. This is because we think of a file
    > as a segment of data that somehow maps well to a segment of memory.
    >
    > You wouldn't execute code from a stream, now, would you?
    >
    > Well, this: http://www.ambric.com/
    >
    > has hardware channels. And you can
    > call from channel
    > and execute code being sent down a channel to you from another cpu.



    >
    > There's no real analogue to this in any OS I've used for a while ...
    >
    > You could write the mcilroy sieve in this very directly. You could
    > even, when starting a new thread, push the code down to the next cpu.
    > And that cpu is paused in a call from channel until it gets its code.
    > A nice way to keep them idle until you need them.
    >
    > it's a very interesting architecture, to say the least. For me anyway
    > the most novel thing I've seen in a while.
    >


    The ARM 7 and ARM 9 procs in the Nintendo DS can talk back and forth via a
    FIFO at a pretty low level :-)

    http://www.double.co.nz/nintendo_ds/nds_develop7.html

    Dave

    >
    > ron
    >
    >



  5. Re: [9fans] mmap

    > has hardware channels. And you can
    > call from channel
    > and execute code being sent down a channel to you from another cpu.

    ....
    > it's a very interesting architecture, to say the least. For me anyway
    > the most novel thing I've seen in a while.


    Interesting but not novel. Remember the transputer, circa 1985? Hardware
    channels, both inter- and intra-chip. The normal way of loading code was
    to read it down a link from another processor - used for bootstrapping
    an array of transputers, but also could be used for dynamic propagation
    of processes through the network.



  6. Re: [9fans] mmap

    On Sat, Aug 2, 2008 at 6:22 AM, Richard Miller <9fans@hamnavoe.com> wrote:
    >> has hardware channels. And you can
    >> call from channel
    >> and execute code being sent down a channel to you from another cpu.

    > ...
    >> it's a very interesting architecture, to say the least. For me anyway
    >> the most novel thing I've seen in a while.

    >
    > Interesting but not novel. Remember the transputer, circa 1985? Hardware
    > channels, both inter- and intra-chip. The normal way of loading code was
    > to read it down a link from another processor - used for bootstrapping
    > an array of transputers, but also could be used for dynamic propagation
    > of processes through the network.
    >


    yes, but IIRC the transputer did not have the ability to execute code
    from a channel in the way the ambric does -- literally having a PC
    that includes a channel ID. There are a few other wrinkles to the
    ambric that make it a little neater than the transputer. Ambric is
    pretty well aware of what the transputer did.

    rno


  7. Re: [9fans] mmap

    > Ambric is
    > pretty well aware of what the transputer did.


    Glad to hear it - there were some good ideas behind the transputer which
    are worth recycling. From your description it sounds like the ambric has
    some interesting new refinements as well.



  8. Re: [9fans] mmap

    * Roman V. Shaposhnik wrote:
    > On Wed, 2008-07-30 at 17:29 +0200, Enrico Weigelt wrote:
    > > Convenience is one point (sometimes be a big point), but another
    > > important one is sharing. Without mmap(), an (real) shared library
    > > support most likely will require special kernel support.

    >
    > What aspect of shared libraries are you aching for? Dynamic
    > linking or the dynamic loading?


    3rd: Sharing pages.

    Well, this perhaps also could be done if the kernel would be able
    to detect equal pages and automatically map them together (maybe
    w/ copy-on-write again).


    BTW mmap() is also nice for creating shared memory between
    (local) processes. For example RDBMS'es can get a huge benetit
    from this.


    cu
    --
    ----------------------------------------------------------------------
    Enrico Weigelt, metux IT service -- http://www.metux.de/

    cellphone: +49 174 7066481 email: info@metux.de skype: nekrad666
    ----------------------------------------------------------------------
    Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
    ----------------------------------------------------------------------


+ Reply to Thread
Page 2 of 2 FirstFirst 1 2