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(), ...). > > 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? > > } 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. I agree with Darren's comment about the system call name. It's odd. Nico --
