Re: [PATCH] 2.6: mmap complement, fdmap

[Matt Mackall <mpm@selenic.com>]

On Mon, Mar 22, 2004 at 01:26:01PM -0600, Matt Miller wrote:
> > > > a) what the hell for?
> > >
> > > It's targetted mainly as a performance enhancer.  Some of the specific
> > > scenarios where it would be useful are:
> > >
> > > a) When one cannot afford to take the performance hit of synchronizing
> > >    a memory range to disk due to disk size limitations or speed
> > >    requirements.
> > > b) Some things can benefit from the ability to interface with
> > memory as a
> > >    file.
> > >
> > > The specific reason for implementing this was to allow for
> > loading dynamic
> > > libraries in the context of a process without having to write them to
> > > disk.
> >
> > How about tmpfs/ramfs instead? Open a file on tmpfs and mmap it and
> > you've got the same thing without any of the nasty corner cases.
> 
> Because tmpfs does not allow you to map a file descriptor to a specific
> memory
> range inside a process.  tmpfs allows you to open a file that exists only
> in memory, yes, but it does not accomplish what fdmap tries to accomplish.
> fdmap allows you to access arbitrary memory ranges as if they were a file.
> tmpfs allows you to access a file that happens to only exist in memory.
> You do not control the address range that tmpfs/ramfs map to.

You don't? Is this not what the first argument of mmap provides? I'm
afraid I can't see how it matters, as you'd have to populate said map
afterwards anyway.

Point is, mmap() is already its own complement and what you're
proposing is a hairy solution in search of a problem as the VFS
maintainer already pointed out.

-- 
Matt Mackall : http://www.selenic.com : Linux development and consulting