On 09/06/2011 02:51 PM, Richard W.M. Jones wrote:
On Sat, Sep 03, 2011 at 10:46:30PM +0200, Gillen Daniel wrote:
> mmap is exactly the problem. I didn't find it in gnulib or somewhere else.
>
> I did some more research on how it could be done and I came up with
> the following. Definitely less invasive :) and full_read and
> full_write can be used again.
>
> What do you think about that one?
The way to do this [mmap] patch less invasively is to use an autoconf
replacement function. (Well actually a better way would be to add the
needed features to gnulib, but I'll assume that you don't want to do
that).
It's all documented here:
https://www.gnu.org/s/hello/manual/autoconf/Generic-Functions.html
https://www.gnu.org/s/hello/manual/automake/LIBOBJS.html
(see AC_LIBOBJ, AC_REPLACE_FUNCS etc).
From upstream (ie. our) point of view, it means the replacement is
stuffed into another file that is only used on Windows and that we
don't have to worry about. From your point of view the advantage is
that you can [in the replacement file] go wild with whatever Windows
specific includes and Win32 APIs you want.
Ok, thx for pointing me in that direction. I'm willing to do it like
that but I have two further questions.
1. This damn windows MapViewOfFile function needs a handle to a file map
object that has to be saved somewhere to be able to close it when
calling munmap. The only way I currently see to save it would be in your
hive_h structure. But this would incorporate that on windows, when
calling mmap and munmap, an additional parameter would have to be
passed. Would that be ok for you or do you have an idea how this could
be solved nicer?
2. What do you request from the mmap / munmap replacement? Should it
only support the functionality currently used in the lib or should it
implement as far as possible all features from the libc mmap / munmap
functions?
--
Unix _IS_ user friendly - it's just
selective about who its friends are!