Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n')

[Stas Sergeev]

02.09.2015 17:08, Andy Lutomirski ÐÐÑÐÑ:
> On Sep 2, 2015 2:51 AM, "Stas Sergeev" <stsp@xxxxxxx> wrote:
>>
>> https://lkml.org/lkml/2015/7/21/208
>>
>> Guys, you gonna be kidding.
>> Is this a new trend of breaking dosemu, or what?
>>
>>> VM86 is entirely broken if ptrace, syscall auditing, or
>>> NOHZ_FULL is in use.  The code is a big undocumented mess, it's
>>> a real PITA to test, and it looks like a big chunk of vm86_32.c
>>
>>
>> It is a CPU feature that kernel should support, and always
>> did without any problems. If it started to have problems because
>> of your actions, then you can as well fix your code.
>>
>>> No one should be using it anyway. Use DOSBOX or KVM instead.
>>
>> Have you done the benchmarks between dosbox and dosemu
>> before saying that? Please do, thanks. (don't forget to include
>> dosemu2 in your benchmarks too, as it outperforms both)
> 
> I wasn't aware of your dosemu variant at the time, and I incorrectly
> thought that dosemu was unmaintained.
This is roughly true to my knowledge, hence the forks.

> Does real mode performance matter any more?
People that control their legacy HW with DOS program wants
the real-time performance. They even run dosemu with non-default
scheduling policies sometimes (although I doubt it really helps).

> The mark_screen_rdonly thing is still kind of scary.  It changes PTEs
> on arbitrary mappings behind the vm's back.
Then you can start removing things step-by-step.
mark_screen_rdonly is likely a bad interface, I wonder if someone
uses it. There are indeed too many legacy things in vm86(), but there
is no point to disable it completely.

> I'd be amenable to switching the default back to y and perhaps adding
> a sysctl to make the distros more comfortable.  Ingo, Kees, Brian,
> what do you think?
I'd say you can just remove what looks bad and fix the rest.
Then disabling it can be done under "if EMBEDDED" only.
Eg, the BIOSSEG stuff looks like a candidate for removal,
return_for_pic, screen_rdonly and many other absolutely
useless things. If it is reduced to the bare minimum, I wonder
if there will still be the desire to make it configurable under
non-if-EMBEDDED.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/