On 23 April 2012 17:48, Stas Sergeev wrote: > What are you optimizing for, why there is even a need to > make the mapping.c functions to call the functions with the > similar names? (sorry for the late reply, I checked things a bit more thoroughly now)
There is of course no need to call functions with similar names, although it is a bit confusing that mmap_mapping() sometimes doesn't call mmap(), it should at least to the caller behave like mmap. Initially I just saw a very janitorial cleanup as combining a sequence: f(x); g(y); into h(x,y); where h(x,y) essentially calls f(x) and g(y), optimizing out redundant code and syscalls, but retaining the possibility to call f(x) and g(y). So I really don't call for a complete revert. I think scratch mapping should stay in mmap_mapping, it really is mmap. Yes, Linux (but not POSIX in general) allows mprotect/mremap on sbrk()'ed regions, but it really is a frontend to mmap with MAP_ANON, because the protections, and the (fixed) hint are relevant. Then alloc_mapping (without kmem), to match valloc() or malloc() should just have one argument apart from cap, that is size. The present target argument is very old, from the times of mapself.c and DPMI memory coming from /dev/zero: the target was the fixed address for DPMI's Allocate Linear Memory Block. Now for the hardware RAM: > The point was exactly that: if we need something > like "DPMI map hardware ram", then we need to allow the user > to put the allowed ranges in the config, and then we can > pre-allocate them while we are still root. That functionality has been there since October 2004 (git commit 879e51 during the 1.3.2 release cycle), and I certainly wouldn't want to kill it. But no actual mapping takes place there and then (inside DPMI function 0x800), all it does is to return the DOS address of the pre-mapped hardware RAM (from alloc_mapping: mmap_mapping does no actual mapping for these addresses, but returns the same thing as the alloc_mapping call just before that, and mprotect()s), since that is sufficient -- however kmem map internals are abused a bit, leaving is_mapped at 0 even when actually mapped in DPMI DOS space, that's entirely my fault). There is also some overlap between the *_hardware_ram() functions and the *_mapping_kmem() functions. Perhaps the cleanest approach is to replace all alloc_mapping(MAPPING_KMEM) calls outside mapping.c by register_hardware_ram(). Then map_hardware_ram() corresponds to open_mapping(MAPPING_KMEM), can just open /dev/mem once, do the mappings, and closes /dev/mem (much like open_mapping does for SHM/tempfile memory). get_hardware_ram() is a lot like mmap_mapping_kmem(); for DPMI the pre-allocated memory doesn't need to be moved, but one could initially protect it PROT_NONE and adjust protections. There is one place that does not play well with the register_hardware_ram mechanism (matrox.c) because it only temporarily maps ram to do a few tests. That could just use mmap_mapping()/munmap_mapping() then with appropriate flags, where no extra work is done. On the other hand, this code hasn't been tested for so long (much like hgc.c, dualmon.c, s3.c, sis.c, etc) for the hardware is so old that an alternative is to just remove it. Perhaps DOSEMU inside Linux in some virtual machine (QEMU, VirtualBox, VMWARE, etc) allows testing some of this code. Yes I know I agreed on your changes many years ago, just because it effectively solved a problem (dealing with /dev/mem mmaps after the priv drop), but it's always possible to clean up, it's not a contract we signed. Sometimes I look at my code from years back and also think that I did things too complicated for not much gain, and it's better to keep things more simple. In fact some of the changes I propose come from my own changes with respect to the *_hardware_ram() functions that muddled things a bit. Bart ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Dosemu-devel mailing list Dosemu-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dosemu-devel
