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
