2008/226: mmapfd(2) - mmap file descriptor

[Michael Corcoran]

On Mon, 2008-03-31 at 10:30 -0500, Nicolas Williams wrote:
> On Mon, Mar 31, 2008 at 01:37:42PM +0200, Roland Mainz wrote:
> > Rod Evans wrote:
> > >   mmapfd(int fd, uint_t flags, mmapfd_result_t *storage,
> > >         uint_t *elements, void *arg)
> > 
> > Uhm... how do I unmap the mapping done by |mmapfd()| ?
> 
> I thought that was clear (each mmapfd_result_t's mr_addr can be used as
> an argument to munmap(), mprotect(), ...).
> 
Correct.

> > >          uint_t          mr_flags;        /* info on the mapping */
> > 
> > Please change this to |uint64_t| (e.g. it may be nice to have more flags
> > available by default).
> 
> Same thing with the flags argument, no?
> 
Same argument could be made.  

> > >    } mmapfd_result_t;
> > > 
> > >    Values for mr_flags include:
> > > 
> > >    MFD_ELF_HDR           0x1     /* the ELF header is mapped at mr_addr */
> > >    MFD_AOUT_HDR          0x2     /* the AOUT header is mapped at mr_addr */
> > 
> > What about reserving the first four bits for |MFD_*_HDR| flags
> > (|MFD_ELF_HDR|, |MFD_AOUT_HDR| and two bits reserved for future
> > |MFD_*_HDR| flags) ?
> 
> Why?  Isn't the ARC going to be the authority for this namespace
> anyways?  My interpretation is that all currently unused flag bits are
> reserved.  Or did you mean that file format shouldn't be a flag but an
> integer value?
> 
> My comments:
> 
> I'm curious about the 'arg' argument.  It's interpretation depends on
> the flags, but presumably there could be many flags in use in one call
> that make use of 'arg'.  My guess is that arg would have to point to a
> concatenation (with padding) in memory of each flag's arg in
> (descending?) numeric order of the flags.  But this is nothing that
> can't be settled when we come to that bridge.
> 
Exactly.  There are probably a few different ways that we could expand
the "arg" argument in the future to handle data needed for new flags. We
made it a void * (pointer to size_t) for just this reason.

> I agree with Darren's comment about the system call name.  It's odd.

I agree.  We'll be changing it to something new.

--Mike

> Nico