21.04.2012 03:55, Bart Oldeman wrote: >> Given the above changelog, do you still need 2 mmaps here? > alloc_mapping call smalloc but doesn't call mmap for mapshm/mapfile. Well, for MAPPING_INIT_LOWRAM it also did alias. But it seems you let the caller do so instead. I am not sure if it is really better: unlike EMS, lowmem always needs to be initially mapped to the DOS space, and the lowmem_base is just an intermediate step, a backing store, so to say. The caller should not care about the intermediate things, so he may expect MAPPING_INIT_LOWRAM to map lowram, so I was fine with how it was before. In contrast, for EMS there is a clear separation between allocation and mapping, so what was good to do for EMS, is not necessary good for lowram. Not a big deal either way though.
> Mostly I was trying (like you) to get rid of some of the confusing > magic in mapping.c: alias_mapping should be a wrapper around > mappingdriver.alias, and alloc_mapping a wrapper around > mappingdriver.alloc. Well, that was not my goal. :) What I wanted is a clean API of mapping.h and a simple code in mapping.c. The relations between mapping.c and the lower level were out of my cleanup, and I wouldn't change an API based on them, but let's see what will this be at the end. > I'm still reviewing and thinking about those. I think the SCRATCH > mmaps could just stay in mmap_mapping (that's then just a simple Maybe, if you are not adding the dst_addr to alloc_mapping(). I added it for MAPPING_INIT_LOWRAM, and then it became logical to also move MAPPING_SCRATCH there. But you did another thing to MAPPING_INIT_LOWRAM (mostly eliminating it), so the things are completely different now. But then I am not sure it is any better. :) But doesn't matter. > printfs). The KMEM stuff: maybe some of it (where it actually opens > /dev/mem and maps areas of this file) should be in open_mapping, > alloc_mapping could give you the right pointer in this area given an > offset in /dev/mem, and alias_mapping maps the DOS address to this > pointer. But IIRC we don't apply alias_mapping() to kmems because /dev/mem lacks the .nopage op, so we can't properly alias it. Instead we flip the area in mmap_mapping() between the DOS space and some anonymously mapped region, doing the copyback as need be. And I wouldn't recomment "emulating" the alias in alias_mapping() in any way, because it will have to be consistent with dosaddr_to_unixaddr(), which will return the lowmem addresses for kmems. So I don't think such a change will make sense. 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? Btw, I think the dosaddr_to_unixaddr() have to be implemented the way you proposed: after I splitted the kmem management in a separate functions, the temptation to use only a single lookup array was multiplied by zero. > There could be one function that combines alloc/alias mapping, but > then again, you want the Unix pointer (i.e. the result of > alloc_mapping) visible for EMS, so it seems better to have them as > separate calls that do separate things. No, EMS should not touch kmems. So I don't think this proposal is very plausible. ------------------------------------------------------------------------------ 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
