On Sun, 30 May 2004, Stas Sergeev wrote: > 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.
Yes that's right. The first 4K still map to the same virtual file with mremap. emm.c I think expects it only to behave as a plain "realloc", historical reasons probably and that's why it works. > > 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. Maybe, but that's more of a kernel issue. mmap certainly isn't guaranteed to extend a file (it works to create a new file though), so in that way mremap is behaving consistently (i.e. if you mmap bytes 4096-8191 of a file with size 4000 you can't expect that file to be extended to 8192 bytes, the same is true for shm virtual files. Look at the ftruncate example in "info libc" to see how they really need the ftruncate. > 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? I think I would personnally like it best if there wasn't a pagealloc either, but just multiple fd's. That way you can have only one mapping backend, it just differs in what the fd opens (i.e. /dev/zero or a temporary file, or perhaps shm_open), and we don't need the mremap trick. That would mean that open_mapping doesn't have to do anything at all. alloc_mapping opens a /dev/zero or tmpfile -- the fd will be remembered (linked list connecting it to the memory address) or it can be returned to the caller. realloc_mapping would have to do ftruncate and then mremap alias_map can mmap from the memory region to the fd. of course the drawback of this is some overhead taking care of the fd's. But that gets rid of the overhead in pagemalloc.c and only allocates on demand (instead of one big chunk in the beginning). Bart - 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
