14.04.2012 06:25, Bart Oldeman написал:
> you should be able to subscribe using
> https://lists.sourceforge.net/lists/listinfo/dosemu-cvs
I was always subscribed there, I checked that many
times, and the mail delivery knob was set to enabled.
Yet you said I was somehow unsubscribed because
of the bounces, and that was true: delivery didn't work
until I posted to the list.
> When mmap_min_addr> 0,
... or selinux is enabled.
You need to adjust an error message to take this into
account. I was very confused when set mmap_min_addr
to 0 yet still receiving the error from dosemu.
> well I agree things should be cleaned up for sure. As far as I can see
> LOWMEM() is only used in a few places -- it could be completely
> removed.
Yep, or to be left only for mappers, as they surely know
what they want to map to the DOS.
> I think the lowmem_base areas are useful as r/w mirrors of
> r/o areas so can be used directly if needed; if the only place that
> adds lowmem_base to a DOS address, based on mapping info, is
> dosaddr_to_unixaddr() then that's fine with me.
OK.
>> What's the use destinguishing the code and the data?
>> If you have an area protected with the CPU emulator
>> and someone writes to it, you'd better invalidate, no
>> matter is it a code or data, or am I missing something?
> The CPU emulator splits a page in 256 chunks of 16 bytes to see for
> which it has generated JIT code.
> As soon as code is generated the whole page is write-protected. If a
> byte is written for which no code is generated (no matter if it is in
> actual fact code or data), there is no problem and you don't need to
> invalidate. It could be that a page consists of 4095 bytes data (or
> 4095 bytes of untranslated code) and1 byte code; yet the page will be
> write-protected, and any data writes to it (by the generated code or
> by DOSEMU itself) will be trapped. In that case you can avoid the trap
> by writing to an unprotected equivalent page.
The trap should _of course_ be avoided. And you _of course_
need to write to an unprotected page: that's why I suggest to
just use dosaddr_to_unixaddr(), and never anything else like
&mem_base[addr]. By the use of the properly written dosaddr_to_unixaddr()
you are guaranteed to not get a fault. (and the kmem's memory
is never write-protected IIRC)
That's why lowmemp() looks exceptionally bad to me, as it
doesn't fit well into that picture.
>> so why not just something like that:
>> #define WRITE_WORD() { \
>> if (cpu_emulator) e_invalidate(); \
>> write_word(); \
>> } while (0)
> so that's too expensive, because you need to do m(un)protect() calls,
> and later regenerate code.
Is this because something is not properly implemented?
I mean, the properly_implemented_e_invalidate(addr, len)
should see if that range should be invalidated, and if not -
just do not do anything at all. Not even unprotect. With
the proterly_written_dosaddr_to_unixaddr() you will not
get trapped, no matter what. So that's how I see it, or am
I expecting too much from the current code? :)
>
>> OK, I still don't understand anything. Firstly, this:
>> ---
>> #define MEMCPY_P2UNIX(unix_addr, dos_addr, n) \
>> memcpy((unix_addr), lowmemp(dos_addr), (n))
>> ---
>> suggests that it takes the DOS address.
> This macro comes from the adjustments to allow DOSEMU to run with
> non-zero base for mmap_min_addr>0. Before, sometimes addresses were
> coded as pointers: e.g. (char *)0x2000 and sometimes as integers. Now
> instead, of using (char *)0x2000 we use&mem_base[0x2000]. Formerly
> the MEMCPY_2UNIX dealt with both integers and pointers by using casts.
> Now this won't work anymore, so I introduced MEMCPY_P2UNIX which takes
> a pointer. Here dos_addr really means "potentially an address in DOS
> space" -- it is potentially converted from&mem_base[xxx] to
> &lowmem_base[xxx]; unix_addr is an address that is *always* in DOSEMU
> space.
Oh... How many places like this there were in the code, so
you decided to add more macros, lowmemp() etc etc, instead
of just fixing all of them to use integers instead of pointers?
If we are talking about hundreds or thousands, then yes,
this was the only way to go... But if there are just a few, why
not to fix them?
>> Secondly, I can't follow the logic. I think we never had the
>> precise definition of what is the linux pointer and what is
>> the DOS pointer.
> Yes that is the man source of confusion here I think :)
I needed to document my ideas when adding lowmem_base. :)
>> I think you are basically working around the lack of the
>> properly functional dosaddr_to_unixaddr(). You shouldn't
>> do p=&mem_base[0xb8000], but rather p=dosaddr_to_unixaddr(0xb8000).
>> Or are there other reasons to keep lowmemp()?
>> I mean, let's aim for simplicity. :) If the meaning of the function
>> is not obvious, it is a suspect for cleanup.
> One problem is that there are still quite a few places that don't use
> the READ_BYTE (etc) macros, and take pointers directly into DOS space
That's horrible... how much of them are still in?
> (e.g. MFS, ReadVTOC in mscdex.c that takes a pointer "buf" that is
> sometimes in Linux and sometimes in DOS space, snprintf in
> dpmi/msdos.c). For those I sometimes need to convert a pointer, e.g.
> &mem_base[0x1000] it points to writable space&lowmem_base[0x1000] to
> avoid page faults.
Well, so you have already converted them to &mem_base[0x1000]
first, and then you convert them to lowmem_base. What's the use?
Why not to just do dosaddr_to_unixaddr()? Simpler code, 1 conversion
instead of 2, no confusion about DOS/linux pointers, etc.
Yes, you would first need to adjust them to be integers instead of
pointers, but I guess, as a quick hack, you can just implement
lowmemp() as follows:
char *lowmemp(void *fuckedup_dos_addr)
{
return dosaddr_to_unixaddr((int)fuckedup_dos_addr);
}
and then remove it when everything is fixed.
>> I think that's a great work!
>> Run win.com, and hooplah - windows-3.1 is up and running on
>> x86-64 dosemu... I'd say WOW! :)
> Even more amazing and weirdly with the non-zero base. In that case the
> real LDT has all offsets shifted by (unsigned int)(&mem_base), e.g.
> when the LDT that DOS applications think they deal with has a segment
> with a base of 0, its entry in the real LDT that is managed using
> modify_ldt() has a base of mem_base.
Great! Good that an app can't get a base directly, like it can
get the limit with lsl.
------------------------------------------------------------------------------
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
