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

--

[ message continues ]

Thanks David, will check it today evening (i'm in office now)
--

[ message continues ]

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?
--

[ message continues ]

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

--

[ message continues ]

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 -

--

[ message continues ]

Peter, Ingo,

any objections on the patch like that?

---
From: Cyrill Gorcunov <gorcunov@gmail.com>
Subject: [PATCH] reintroduce old VM86 flags for userlang backward compatibility

Signed-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
--

[ message continues ]

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
--

[ message continues ]

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

--

[ message continues ]

Ok, lets drop these all and forget :)
--

[ message continues ]

We still want to shift the definition of X86_VM_MASK inside __KERNEL__,
don't we?

-- 
dwmw2

--

[ message continues ]

Yes.

	-hpa
--

[ message continues ]

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 -
--

[ message continues ]

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
--

[ message continues ]

Well, I think so too. Matthew?

Rafael
--

[ message continues ]

Yes, though I don't think any of them use these internal flags.

-- 
Matthew Garrett | mjg59@srcf.ucam.org
--

[ message continues ]

[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 -
--

[ message continues ]