This is user-visible. Yet we're changing the name and also making it
depend on #ifdef CONFIG_VM86, which is not going to be set in userspace.
Perhaps it should be within #ifdef __KERNEL__?--
dwmw2--
Thanks David, will check it today evening (i'm in office now)
--
Hi David,
actually, this CONFIG_VM86 was there even before the renaming was done.
The main questions (imo) - is there any user space application who uses
these flags? If they are - then even the idea of this patch was a bit bogus,
and I should *not* remove all these VM86 specific flags but better define them
as aliases on flags from processor-flags.h.Ingo? Peter?
--
Hard to know. VM86 is only used by a handful of applications (DOSEMU,
X.org, others?) but it's hard to know what exactly they are.The fact that noone hollered when that CONFIG_VM86 went in is probably a
good hint that they don't matter, but it's hard to say for sure.-hpa
--
I believe vbetool and thus s2ram uses vm86, too.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
Well, I think so too. Matthew?
Rafael
--
Yes, though I don't think any of them use these internal flags.
--
Matthew Garrett | mjg59@srcf.ucam.org
--
[Matthew Garrett - Sun, Apr 27, 2008 at 12:55:37PM +0100]
| On Sun, Apr 27, 2008 at 01:31:17PM +0200, Rafael J. Wysocki wrote:
| > On Sunday, 27 of April 2008, Pavel Machek wrote:
| > > I believe vbetool and thus s2ram uses vm86, too.
| >
| > Well, I think so too. Matthew?
|
| Yes, though I don't think any of them use these internal flags.
|
| --
| Matthew Garrett | mjg59@srcf.ucam.org
|Originally this flag was bounded by CONFIG_VM86 which is
kernel internal feature and if userland program relies on
this it's a bit buggy assumption meguess. Anyway, i've posted
second version of the patch (don't remember lkml.org link for
that).
- Cyrill -
--
Peter, Ingo,
any objections on the patch like that?
---
From: Cyrill Gorcunov <gorcunov@gmail.com>
Subject: [PATCH] reintroduce old VM86 flags for userlang backward compatibilitySigned-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
---Index: linux-2.6.git/include/asm-x86/vm86.h
===================================================================
--- linux-2.6.git.orig/include/asm-x86/vm86.h 2008-04-23 22:38:58.000000000 +0400
+++ linux-2.6.git/include/asm-x86/vm86.h 2008-04-23 22:41:06.000000000 +0400
@@ -14,6 +14,18 @@#include <asm/processor-flags.h>
+/* backward compatibility for userland */
+#ifndef __KERNEL__
+#define TF_MASK X86_EFLAGS_TF
+#define IF_MASK X86_EFLAGS_IF
+#define IOPL_MASK X86_EFLAGS_IOPL
+#define NT_MASK X86_EFLAGS_NT
+#define AC_MASK X86_EFLAGS_AC
+#define VIF_MASK X86_EFLAGS_VIF
+#define VIP_MASK X86_EFLAGS_VIP
+#define ID_MASK X86_EFLAGS_ID
+#endif
+
#ifdef CONFIG_VM86
#define X86_VM_MASK X86_EFLAGS_VM
#else
--
Well, I would prefer to try to get rid of them; as you said, most
userland don't rely on these, and if they aren't used they are just
namespace pollution, and rather bad such.-hpa
--
Yeah, I'd prefer just to kill them off if we think we can get away with
it. These are hardware-defined flags, not Linux-specific, so userspace
should probably get them from elsewhere anyway.--
dwmw2--
Ok, lets drop these all and forget :)
--
We still want to shift the definition of X86_VM_MASK inside __KERNEL__,
don't we?--
dwmw2--
Yes.
-hpa
--
I've just posted the patch, please review (i'm to go out of
my work machine so if there would be any objections I read
them today evening, thanks)- Cyrill -
--
Actually, being google a bit I found that most of emulators
redefine their own equvalence of these flags. So I think
we could remain all as is. But if we wanna be sure I could
make a patch like this...
#define CF_MASK X86_EFLAGS_CF
...- Cyrill -
--
