Michael Corcoran writes: > > ... what renaming the call to |mmapexecfd()| (= "memory map of > > executable fd") ? > > > I like Darren's suggestion of mmapv(2) better so far. Why limit us to > only being able to interpret executable files? What if there's some > other non-executable file type that would naturally use this interface?
(Everyone loves a good naming project, right? ;-) The implication of "v" in those existing interfaces is that the caller is in control of the vector, and that's not true for this new case, so it's not quite like readv/writev. I think I like `mmapobj' better, with "object" referring to a generic name for a thing, rather than meaning "object file." If we later want to extend it to other files that have embedded structure (say, OLE), we could do it. The only problem we'd have is that some of those other structured types allow _nested_ elements, and it's a little unclear how that'd work out in a nice flat address space ... but I guess I'm not worried. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
