26.05.2012 16:48, Bart Oldeman wrote:
> On 26 May 2012 08:05, Stas Sergeev<s...@list.ru> wrote:
>> And I already have the mail like "why dosemu is running fast
>> as root, and is slow running as user". I think this change should
>> be undone. Yes, the non-zero lowmem base is a great work,
>> cheers and regards, but, as long as it is hopelessly slower than
>> vm86, I think the user have to be notified the hardest possible way.
> The question is just how to do this? Before the change you had to
> choose between manually setting cpu_emu=vm86 in dosemu.conf/dosemurc
> or adjusting mmap_min_addr (perhaps also selinux, not sure how). Then
> the Debian package was changed to set cpu_emu as vm86 as default
> (including root), which I don't think is the best solution either, so
> I change to have things work automatically.
I don't follow the logic.
Debian enabled the CPU-emu by default, and you converted the
error to warning to keep the things working? Doesn't make sense. %)
I don't know how exactly $_cpu_emu option currently works,
but I think it is inconsistent. It seems to me "off" is currently
used as "auto" to default either to "off" or to "vm86", depending
on an arch and on a zero-base availability. If this understanding
is correct, then I propose to make "off" to depend only on an
arch, and invent "auto", which will also take zero-base availability
into account.
> Perhaps the best would be (under X) to display the emulation status in
> the title bar,
Sounds nice to me (this also works under xterm)
> Also, for 64bit dosemu I can't see any
> difference so what should you put there?
> Please install 32-bit Linux and run as root for full performance?
:)
Well, that may depend on $_cpu_emu setting. For "off" you may
do an error (with the fall-back to "vm86"), and with "auto" - nothing
is wrong.
Its just that the user who _really_ wants a fast dosemu, should
give the hints. So the 64bit problem must be simply mentioned
in docs, and in a boot.log. The doc can also mention the vm86_64
patch, etc. I am surprised that people are still using dosemu in
production and are striving to run it as fast as ever possible, but
that's what actually happens.
On a side note, IIRC the qemu people claim that the jit codegen
can be as fast (or faster) than the vm86. Any ideas why this is
not the case with dosemu? :)
> BTW, I think the msdos.c EMS frame usage can continued to done the old
> way without using handles. It can even be changed to only use EMS API
> functions as follows:
>
> in prepare_ems_frame:
>
> static const u_short unmap[] = {0xffff, 0, 0xffff, 1, 0xffff, 2, 0xffff,
> 3};
> if (MSDOS_CLIENT.ems_map_buffer == NULL)
> MSDOS_CLIENT.ems_map_buffer = malloc(emm_get_size_for_page_map());
> emm_get_map_registers(MSDOS_CLIENT.ems_map_buffer);
> /* here 0 is the OS handle; the handle is irrelevant when doing
> unmappings */
> emm_map_unmap_multi(unmap, 0, 4);
>
> Then restore_ems_frame uses emm_set_map_registers as before. This will
> also restore conventional RAM mappings which would be expensive if
> mmap() were called,
Yes, that's the disadvantage: excessive mmaps, excessive buffer allocs.
You don't even need the per-client buffer: you need only one, and
just for 4 pages, not more, not less.
Also, I am not very fond of the "unmap" trick: too dosemu-specific,
against the EMS specs (or my understanding of them), will not port
to DOS.
Maybe you can use OS_handle for save/restore, but even then it
would be nice to allocate one more.
What exactly is a problem with allocating the handles?
It is not a valueable resource, unless you also allocate the pages
to it, which you do not. The apps usually allocate 0 to 2 handles,
so there is never a shortage. Does it hurt you only that it shows
in mem?
------------------------------------------------------------------------------
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
