23.04.2012 23:48, Bart Oldeman wrote: > On 23 April 2012 02:08, Stas Sergeev<s...@list.ru> wrote: >> 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. >> >> 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? > I see what you mean; however, alloc_mapping is always immediately > followed by mmap_mapping for a good reason: there is no reason to > delay the mmap into DOS space until the priv drop. What we needed was > simply a way to map and unmap video ram using mremap when switching > consoles, without having root, and without having mem_fd open. Why? DPMI had something like "map hardware ram" IIRC, and EMM have something like DMA mapping etc. Not that dosemu does implement all of this, but what's the use making the possible implementation impossible? 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?
> So it's actually simpler to just map straight into DOS space before > the priv drop. Then the old alloc_mapping()/mmap_mapping() sequence > becomes a straight mmap_mapping() (because that's what it does, call > mmap() on /dev/mem), and the mmap_mapping() after priv_drop could be > renamed a new function, perhaps mremap_mapping(), that calls mremap(). > I'm sure that simplifies the code significantly without changing the > actual functionality. Well, there should be no problem calling it mremap_mapping() instead of mmap_mapping_kmem() that I was proposing, in case you stuck with this new naming convention. But changing the logic of alloc_mapping() will complicate things in the future, and I don't see the point doing this now, if it was well discussed (with you!) 7 years ago. 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. Furthermore, it is not entirely unrealistic for /dev/mem to have .nopage one day (I even think I had a patch sometime many years ago), and so what is the use sticking it to "mremap" now, even if it is just a name? mapping.c is exactly an _abstraction_, so it should not, by design, expose its internals this way, IMHO. For instance, alias_mapping() does exactly mremap() too, yet it is not called mremap_mapping(). And MAPPING_SCRATCH is basically a malloc(), so I thought it would make much more sense to have it as alloc_mapping_kmem(), than to call it mmap_xxx() just because it happened to use mmap() (it could use sbrk() instead). Not that I want to argue too much over this, but the thing is, we already discussed that, the agreement was reached, the implementation was done, it even still works. :) Just needs a few cleanups, but not a complete revert... ------------------------------------------------------------------------------ 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
