23.04.2012 05:12, Bart Oldeman wrote: > On 21 April 2012 06:04, Stas Sergeev wrote: >> It is better to have open_mapping() to open /dev/mem, >> alloc_mapping_kmem() to map it somewhere, and mmap_mapping_kmem() >> to do the flip - that's what I did in my patchset. Why don't >> you like that approach? > Hmm, I don't see open_mapping changes in your patches. It would then have been open_mapping_kmem() :) Maybe later, but doesn't look like a huge deal.
> Maybe I missed > it. In any case, I think I found a simpler approach (attached) for > kmem, by first observing that alloc_mapping(MAPPING_KMEM...) was > always immediately followed by a call to mmap(). The only place where > they are not paired (just mmap_mapping there) is map_video_ram() in > vc.c. > So they can just be combined; and the call in map_video_ram() can > still do the right thing (skipping the actual mmap to /dev/mem, and > just doing mremap) by looking at kmem_map. The split was intentional and discussed: alloc_mapping() was supposed to do before dropping privs and closing mem_fd. Basically you want to restore the code to the 7 years old state. > In the end that changes mmap_mapping for KMEM to do what it should do > conceptually, map an area of /dev/mem. What goes on behind the scenes > (the remapping) is just to avoid reopening /dev/mem because root was > dropped but the caller doesn't need to know these details. Yes, but you add the subtle requirement to run the _first_ mmap_mapping_kmem() before the root drop. This will work perhaps, but what's the use? Maybe simply unpairing the calls to have mmap_mapping_kmem() at a later stages than now? Btw, you don't need to write the logs like Remove unused MAPPING_SHM and .mmap method from mapping code (Stas Sergeev). any more because "git am" is cool. :) ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ Dosemu-devel mailing list Dosemu-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dosemu-devel
