IIRC your argument, that made sense to me,
was that with such an approach, you can only
expand the backing-store, but never shrink.
I agree this is a problem from some point of
view. I have no idea whether it is important
or not, but it definitely _looks_ not very good.
Well, this generates a bus error, while, for
example, doing the same trick with having a
/dev/mem as a backing-store, simply maps the
"enlarged" space with the anonymous memory,
and so does not generate a SIGBUS (not producing
a desired effect either, of course).
Why do we have it both ways? Shouldn't they
(i.e. /dev/zero and /dev/mem mapping) behave
the same after expanding with mremap?
I was thinking about it a bit, and I imagined
we need something like
int mopen(void *addr, size_t len, unsigned int flags);
which will give you an fd for the memory area,
which you can then ftruncate() and mmap() (and
It looks like vmsplice() is a very close one,
but unfortunately it involves pipe, which will
not give you an ability to ftruncate() I suppose.
I even asked Jens Axboe about the possibility
to have mopen(). He said it might be a good
optimization (having only one syscall whereas
now 2 are needed (pipe/vmsplice)), but not
worth an efforts.
Now, if maybe someone have a time and patience,
he can explain me what was an advantage of using
pipe with vmsplice() at all. Why it was not
possible to have something like the mopen() above,
that will give you an fd right away, without a
pipe, so that ftruncate/mmap/lseek etc can be
used on it? Well, I guess this was discussed
many times, but I failed to google anything
Such a thing could solve that mremap() problem
that me and William Tambe have.