Hello.
Bart Oldeman wrote:
But it still uses mremap(), although not with a shared mem.yes of course, so that comment should be in dosext/dpmi/memory.c then I guess.
What I was (implicitly) asking is whether it is safe to use mremap() at least in this case. It doesn't work reliably on 2.6 kernels even though it is used on a private mapping and I was wondering whether or not it is safe for 2.4 et al. It looks like mremap() is not something to rely upon :(
New pages are not aliased, that's forI'm not sure what you exactly mean here
sure, but is this always true also for
the old ones?
What I mean is: You have a 4K-region aliased like this: 0x40020000 -> 0xe0000 Then you resize it to 8K. With mremap() the above alias should still be valid (I think), and with memcpy() you'll have to update the mapping explicitly.
but it looks like emm.c takes care of remapping everything.
Very probably, but that was the subject for cleanups. I think the mapping subsystem should try to preserve the aliases at realloc itself, and if it does so for mapfile, I think it should do that also for mapshm.
a real file you'd have to ftruncate it to the new size first. But here we don't have a fd to call ftruncate.
But I wonder if SIGBUS is a correct behaviour. I would expect mremap() (nopage handler actually) to do everything that necessary, including ftruncate(). Otherwise it looks broken to me.
We would only be able to use ftruncate+mremap with explicit /dev/zero mappings or shm_open
So should we get back to pagemalloc for mapshm then? After all we still don't need IPC SHM, and pagemalloc perhaps doesn't really hurt? - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
