Hi. Hugh Dickins wrote:
You've answered your own question: we did not make the change Stas suggested, IIRC because I remained a little uneasy with that change in behaviour, and nobody else spoke up for it.
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.
//why does this failed. I am well in the interval [4096, 8192] *(unsigned int *)(ptr + 4096 + 8)= 10; }
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 haven't given it any thought since then:
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 mremap). 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 relevant... Such a thing could solve that mremap() problem that me and William Tambe have. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
